From patchwork Thu Oct 22 20:52:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew MacLeod X-Patchwork-Id: 1386427 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=t5cGN9W+; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CHKLg5bMpz9sTD for ; Fri, 23 Oct 2020 07:52:43 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9E7A43851C09; Thu, 22 Oct 2020 20:52:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E7A43851C09 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1603399961; bh=d5MK+BrtGKbKn+6w4Y3t1elmeOd8mp00gRy8kAwTl1o=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=t5cGN9W+bwtVqeshuTwgjFfZdJ4x4L5Mqb9fEA/0FM7zop6FGA7dYfUuOqgikmyvu OgifELfZ91Fw2/+kHRmgVNd60KoWJGMUc6NbyM8aRFkCPYqo0jKSX2u4wShw1Bsu+p 9OOSBmnW2hETg8DK5PArCxM4pMPuWSo2T3T0CgoY= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id B8796385783D for ; Thu, 22 Oct 2020 20:52:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8796385783D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-237-5LLgpxshMYyPOaYkbJoaHg-1; Thu, 22 Oct 2020 16:52:36 -0400 X-MC-Unique: 5LLgpxshMYyPOaYkbJoaHg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B3581803F42; Thu, 22 Oct 2020 20:52:34 +0000 (UTC) Received: from [10.10.118.239] (ovpn-118-239.rdu2.redhat.com [10.10.118.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id CA61E60C04; Thu, 22 Oct 2020 20:52:32 +0000 (UTC) Subject: [PATCH] Use precision and sign to compare types for ranges - update To: Eric Botcazou References: <29040f71-dacd-f887-6dcb-e7f307e0e010@redhat.com> <9405047.ErREDHvczu@fomalhaut> <60a7341b-eaf7-6be2-9e6e-342290128674@redhat.com> Message-ID: Date: Thu, 22 Oct 2020 16:52:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <60a7341b-eaf7-6be2-9e6e-342290128674@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Andrew MacLeod via Gcc-patches From: Andrew MacLeod Reply-To: Andrew MacLeod Cc: iain@sandoe.co.uk, gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" On 10/22/20 3:16 PM, Andrew MacLeod via Gcc-patches wrote: > On 10/22/20 12:53 PM, Eric Botcazou wrote: >>> There are a few places in the ranger where we sanity check the types of >>> the ranges.  We were using types_compatible_p() but thats not really >>> acccurate as gimple allows types which are useless_type_conversion_p() >>> in only one direction, whereas types_compatible_p() requires casts in >>> both directions to be useless_type_conversion_p(). >>> >>> And, since its only a sanity check, ranges really only require that the >>> precision and sign be the same, so its a faster check anyway. >>> >>> bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed. >> The Ada regression comes from this hunk: >> >> diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc >> index c4bfc658319..983f4c97e87 100644 >> --- a/gcc/gimple-range-gori.cc >> +++ b/gcc/gimple-range-gori.cc >> @@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs) >>       case BIT_AND_EXPR: >>       case BIT_IOR_EXPR: >>         // Bitwise operations on single bits are logical too. >> -      if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)), >> +      if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)), >>                     boolean_type_node)) >>           return true; >>         break; >> >> which overlooks that boolean_type_node may have a precision not equal >> to 1 >> (it's 8 in Ada).  See useless_type_conversion_p which has: >> >>        /* Preserve conversions to/from BOOLEAN_TYPE if types are not >>      of precision one.  */ >>        if (((TREE_CODE (inner_type) == BOOLEAN_TYPE) >>        != (TREE_CODE (outer_type) == BOOLEAN_TYPE)) >>       && TYPE_PRECISION (outer_type) != 1) >>     return false >> > bah.  And I cant seem to reproduce it on my machine with your > reproducer, but I am seeing the other result it in my log. Point is > still taken tho. > range_compatible_p should only be used during asserts as a sanity > check for range interactions, not during actual code processing like > that. > > im currently testing the following, which reverts 2 places (both which > check for logicals)  to use types_compatible_p instead.  The remaining > uses are in range assertion code. This seems to resolve the original > problem in my log. > > Thanks for reducing it to the problematic change.  I'm verifying a new > failure in libgomp isnt a result of this before I check it in. > > Andrew Sorry for missing the regression.. it was there, it just snuck by me in the noise :-P THis seems to resolve the issue on my end, and its the right thing. Bootstrapped on x86_64-pc-linux-gnu, no regressions, for SURE this time, pushed. Author: Andrew MacLeod Date: Thu Oct 22 15:39:37 2020 -0400 Use precision and sign to compare types for ranges Updated to only use range_compatible_p in range assert sanity checks, not for actual type cmpatibility. * gimple-range-gori.cc (is_gimple_logical_p): Use types_compatible_p for logical compatibility. (logical_stmt_cache::cacheable_p): Ditto. diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc index 983f4c97e87..5d50b111d2a 100644 --- a/gcc/gimple-range-gori.cc +++ b/gcc/gimple-range-gori.cc @@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs) case BIT_AND_EXPR: case BIT_IOR_EXPR: // Bitwise operations on single bits are logical too. - if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)), + if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)), boolean_type_node)) return true; break; @@ -1165,7 +1165,7 @@ bool logical_stmt_cache::cacheable_p (gimple *stmt, const irange *lhs_range) const { if (gimple_code (stmt) == GIMPLE_ASSIGN - && range_compatible_p (TREE_TYPE (gimple_assign_lhs (stmt)), + && types_compatible_p (TREE_TYPE (gimple_assign_lhs (stmt)), boolean_type_node) && TREE_CODE (gimple_assign_rhs1 (stmt)) == SSA_NAME) {