Message ID | ZRfuG4OTJ0glNRUG@tucnak |
---|---|
State | Unresolved |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp290824vqb; Sat, 30 Sep 2023 02:45:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFUi14xGWXpL1AlHAN97Vi9BMHYLiJtTJl/QR2rvefRZFhDRJSRL4YBl9wj1sOhlqyV7Ppt X-Received: by 2002:aa7:df17:0:b0:530:d6e5:9229 with SMTP id c23-20020aa7df17000000b00530d6e59229mr6397589edy.10.1696067137592; Sat, 30 Sep 2023 02:45:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696067137; cv=none; d=google.com; s=arc-20160816; b=V5VKdn5E7bo2GaPZdjMo0/MGdBe9GG68bnEmr2zmnjoXVH/Ni5e+389aoOPJujCmI+ StfODLhycc4pJ3ea7qHH0jlXbu2pBqwyoV8iJGq7/Gm3qNLB/lvCxU+SuqyZOSBzuwCw REl6fa1fGVwT/lcwG+OrPqOAyAVihK4Rx//KUVVqUdK6QOxOBBC89T2RI+/8XAzQ5mqi zlyehSFwZdQ8epwup5mfTr30oRC1bSSXjUc6CqaUbdfZ6rtP1UyiRVvZzya/pF0+r2R1 hXM0YdxWfQmdPVdbHDYP7ZbDbkWlOBK7bEOaAvAC5eTDSVHVsXxmgcIQbdsGd8x5+1eR rURA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:reply-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature :dmarc-filter:delivered-to; bh=yxExmXlWad4y0zedvkUow4Kg9K7eKMdeYEcYcaqR5og=; fh=yUb5n+SQyRJ2LPzcwKKr0ljoW/9jUIKYohZMxsDWu7w=; b=sAEk+WhwQDZRJLMJ8eFEFb9Vu34HjPAKegVcgGDsJqDLVabUjrrp44SYuyHLjAJaFn FpTFXnOctotnJDws965Z1rOcQjz6JqIodX0PTU6zsVRQKUQsrTdKMY+eO6dGHi34gHzX 959S6INWhSzV2jfkVxI0LEELjUxNxbj0BKtgJYtTghxe3Y8ne+SyX91N77P3WOQVDKIG qoiFlfFZUp2jZOgw5x/ia+2NdOQaqx1HfCE4hNAM7NMqxOm8AjKLw+VvNqMbf8WvFmRK 4tvFaYSL6H1uEIp14H7goB9MJDq5YoPYp7IcEQ0MOovV1eHmRFG5Tmpo8cdzuiLYvqtC vr2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=irGBWyos; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id t22-20020aa7d4d6000000b0053778302c33si1468950edr.647.2023.09.30.02.45.37 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Sep 2023 02:45:37 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=irGBWyos; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 240FC3831E3D for <ouuuleilei@gmail.com>; Sat, 30 Sep 2023 09:45:33 +0000 (GMT) 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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CEE0D3858C20 for <gcc-patches@gcc.gnu.org>; Sat, 30 Sep 2023 09:45:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CEE0D3858C20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696067108; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=yxExmXlWad4y0zedvkUow4Kg9K7eKMdeYEcYcaqR5og=; b=irGBWyosNHXWldo/Lp0QPOXARNN0fW8Ai02QdvOXi9T96PBLTJA8UQw0pEf0f9J0GHu6OZ zDNmqhbBFME2CrzC6fRtOfzsX583KNIqVD8avAED/9RCpzj1ov8xTZOPgGt5XBKsyX9UAw c8yZok4MG7dhGLwGO6SfNdGz44/bjqk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-632-Skdgt9CINRmNSnYhVv1qAw-1; Sat, 30 Sep 2023 05:45:04 -0400 X-MC-Unique: Skdgt9CINRmNSnYhVv1qAw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3FE2B29AA2DB; Sat, 30 Sep 2023 09:45:04 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F1AC1140E912; Sat, 30 Sep 2023 09:45:03 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 38U9j0sa3514835 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 30 Sep 2023 11:45:01 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 38U9j05F3514834; Sat, 30 Sep 2023 11:45:00 +0200 Date: Sat, 30 Sep 2023 11:44:59 +0200 From: Jakub Jelinek <jakub@redhat.com> To: Richard Biener <rguenther@suse.de>, Andrew Pinski <apinski@marvell.com> Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] match.pd: Avoid another build_nonstandard_integer_type call [PR111369] Message-ID: <ZRfuG4OTJ0glNRUG@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_SBL_CSS, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Reply-To: Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778455295109475142 X-GMAIL-MSGID: 1778455295109475142 |
Series |
match.pd: Avoid another build_nonstandard_integer_type call [PR111369]
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Jakub Jelinek
Sept. 30, 2023, 9:44 a.m. UTC
Hi! I really can't figure out why one would need to add extra casts. type must be an integral type which has BIT_NOT_EXPR applied on it which yields all ones and we need a type in which negating 0 or 1 range will yield 0 or all ones, I think all integral types satisfy that. This fixes PR111369, where one of the bitint*.c tests FAILs with GCC_TEST_RUN_EXPENSIVE=1. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-09-30 Jakub Jelinek <jakub@redhat.com> PR middle-end/111369 * match.pd (a?~t:t -> (-(a))^t): Always convert to type rather than using build_nonstandard_integer_type. Jakub
Comments
On Sat, Sep 30, 2023 at 11:44:59AM +0200, Jakub Jelinek wrote: > I really can't figure out why one would need to add extra casts. > type must be an integral type which has BIT_NOT_EXPR applied on it > which yields all ones and we need a type in which negating 0 or 1 > range will yield 0 or all ones, I think all integral types satisfy > that. > This fixes PR111369, where one of the bitint*.c tests FAILs with > GCC_TEST_RUN_EXPENSIVE=1. Though, I think there is an preexisting issue which the build_nonstandard_integer_type didn't help with; if type is signed 1-bit precision, then I think a ? ~t : t could be valid, but -(type)a would invoke UB if a is 1 - the cast would make it -1 and negation of -1 in signed 1-bit invokes UB. So perhaps we should guard this optimization on type having element precision > 1 or being unsigned. Plus the (convert:type @2) didn't make sense, @2 already must have TREE_TYPE type. So untested patch would be then: 2023-09-29 Jakub Jelinek <jakub@redhat.com> PR middle-end/111369 * match.pd (a?~t:t -> (-(a))^t): Always convert to type rather than using build_nonstandard_integer_type. Punt if type is signed 1-bit precision type. --- gcc/match.pd.jj 2023-09-29 18:58:42.724956659 +0200 +++ gcc/match.pd 2023-09-30 11:54:16.603280666 +0200 @@ -6741,13 +6741,9 @@ (define_operator_list SYNC_FETCH_AND_AND (with { bool wascmp; } (if (INTEGRAL_TYPE_P (type) && bitwise_inverted_equal_p (@1, @2, wascmp) - && (!wascmp || element_precision (type) == 1)) - (with { - auto prec = TYPE_PRECISION (type); - auto unsign = TYPE_UNSIGNED (type); - tree inttype = build_nonstandard_integer_type (prec, unsign); - } - (convert (bit_xor (negate (convert:inttype @0)) (convert:inttype @2))))))) + && (!wascmp || element_precision (type) == 1) + && (!TYPE_OVERFLOW_WRAPS (type) || element_precision (type) > 1)) + (bit_xor (negate (convert:type @0)) @2)))) #endif /* Simplify pointer equality compares using PTA. */ Jakub
On Sat, 30 Sep 2023, Jakub Jelinek wrote: > Hi! > > I really can't figure out why one would need to add extra casts. > type must be an integral type which has BIT_NOT_EXPR applied on it > which yields all ones and we need a type in which negating 0 or 1 > range will yield 0 or all ones, I think all integral types satisfy > that. It seems to work for bool, so indeed. > This fixes PR111369, where one of the bitint*.c tests FAILs with > GCC_TEST_RUN_EXPENSIVE=1. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Richard. > 2023-09-30 Jakub Jelinek <jakub@redhat.com> > > PR middle-end/111369 > * match.pd (a?~t:t -> (-(a))^t): Always convert to type rather > than using build_nonstandard_integer_type. > > --- gcc/match.pd.jj 2023-09-28 11:32:16.122434235 +0200 > +++ gcc/match.pd 2023-09-29 18:05:50.554640268 +0200 > @@ -6742,12 +6742,7 @@ (define_operator_list SYNC_FETCH_AND_AND > (if (INTEGRAL_TYPE_P (type) > && bitwise_inverted_equal_p (@1, @2, wascmp) > && (!wascmp || element_precision (type) == 1)) > - (with { > - auto prec = TYPE_PRECISION (type); > - auto unsign = TYPE_UNSIGNED (type); > - tree inttype = build_nonstandard_integer_type (prec, unsign); > - } > - (convert (bit_xor (negate (convert:inttype @0)) (convert:inttype @2))))))) > + (bit_xor (negate (convert:type @0)) (convert:type @2))))) > #endif > > /* Simplify pointer equality compares using PTA. */ > > Jakub > >
On Sat, 30 Sep 2023, Jakub Jelinek wrote: > On Sat, Sep 30, 2023 at 11:44:59AM +0200, Jakub Jelinek wrote: > > I really can't figure out why one would need to add extra casts. > > type must be an integral type which has BIT_NOT_EXPR applied on it > > which yields all ones and we need a type in which negating 0 or 1 > > range will yield 0 or all ones, I think all integral types satisfy > > that. > > This fixes PR111369, where one of the bitint*.c tests FAILs with > > GCC_TEST_RUN_EXPENSIVE=1. > > Though, I think there is an preexisting issue which the > build_nonstandard_integer_type didn't help with; if type is signed 1-bit > precision, then I think a ? ~t : t could be valid, but -(type)a would invoke > UB if a is 1 - the cast would make it -1 and negation of -1 in signed 1-bit > invokes UB. > So perhaps we should guard this optimization on type having element precision > 1 > or being unsigned. Plus the (convert:type @2) didn't make sense, @2 already > must have TREE_TYPE type. Alternatively cast to unsigned:1 in that case? OTOH when element precision is 1 we can also simply elide the negation? > So untested patch would be then: > > 2023-09-29 Jakub Jelinek <jakub@redhat.com> > > PR middle-end/111369 > * match.pd (a?~t:t -> (-(a))^t): Always convert to type rather > than using build_nonstandard_integer_type. Punt if type is > signed 1-bit precision type. > > --- gcc/match.pd.jj 2023-09-29 18:58:42.724956659 +0200 > +++ gcc/match.pd 2023-09-30 11:54:16.603280666 +0200 > @@ -6741,13 +6741,9 @@ (define_operator_list SYNC_FETCH_AND_AND > (with { bool wascmp; } > (if (INTEGRAL_TYPE_P (type) > && bitwise_inverted_equal_p (@1, @2, wascmp) > - && (!wascmp || element_precision (type) == 1)) > - (with { > - auto prec = TYPE_PRECISION (type); > - auto unsign = TYPE_UNSIGNED (type); > - tree inttype = build_nonstandard_integer_type (prec, unsign); > - } > - (convert (bit_xor (negate (convert:inttype @0)) (convert:inttype @2))))))) > + && (!wascmp || element_precision (type) == 1) > + && (!TYPE_OVERFLOW_WRAPS (type) || element_precision (type) > 1)) > + (bit_xor (negate (convert:type @0)) @2)))) > #endif > > /* Simplify pointer equality compares using PTA. */ > > > Jakub > >
--- gcc/match.pd.jj 2023-09-28 11:32:16.122434235 +0200 +++ gcc/match.pd 2023-09-29 18:05:50.554640268 +0200 @@ -6742,12 +6742,7 @@ (define_operator_list SYNC_FETCH_AND_AND (if (INTEGRAL_TYPE_P (type) && bitwise_inverted_equal_p (@1, @2, wascmp) && (!wascmp || element_precision (type) == 1)) - (with { - auto prec = TYPE_PRECISION (type); - auto unsign = TYPE_UNSIGNED (type); - tree inttype = build_nonstandard_integer_type (prec, unsign); - } - (convert (bit_xor (negate (convert:inttype @0)) (convert:inttype @2))))))) + (bit_xor (negate (convert:type @0)) (convert:type @2))))) #endif /* Simplify pointer equality compares using PTA. */