From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 65C593857C53 for ; Tue, 18 Jan 2022 16:49:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 65C593857C53 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-463-227Nusb2NZy1lZbc4YAfxA-1; Tue, 18 Jan 2022 11:49:52 -0500 X-MC-Unique: 227Nusb2NZy1lZbc4YAfxA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E57F51932480; Tue, 18 Jan 2022 16:40:52 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.40.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79B3454449; Tue, 18 Jan 2022 16:40:50 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20IGemcn3102015 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 18 Jan 2022 17:40:48 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20IGemQW3102014; Tue, 18 Jan 2022 17:40:48 +0100 Date: Tue, 18 Jan 2022 17:40:48 +0100 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: [PATCH] c++: Further address_compare fixes [PR89074] Message-ID: <20220118164048.GD2646553@tucnak> Reply-To: Jakub Jelinek References: <20220106092416.GX2646553@tucnak> <494ae254-aff9-8be9-1cee-5ee42b6db593@redhat.com> <20220118101741.GW2646553@tucnak> <841aeb56-57a3-07b3-dbc0-a45ef0cca554@redhat.com> MIME-Version: 1.0 In-Reply-To: <841aeb56-57a3-07b3-dbc0-a45ef0cca554@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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-List-Received-Date: Tue, 18 Jan 2022 16:49:58 -0000 On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote: > > Can you please comment on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1 > > then? > > Done. Thanks. > About the rest of the patch, I thought I had seen richi comment on IRC (but > can't find the comment now) that these cases where we could give a constant > answer but decide not to because of C++ rules should be handled in the front > end rather than generic code, which makes sense to me; that is, use > folding_initializer only for giving more constant results, not for giving > fewer constant results. Maybe add another flag for limiting constant > results if we think it's significantly easier to recognize these cases in > fold? I'm afraid avoiding the match.pd & fold-const code here would be a lot of work. The match.pd code looks like: (for cmp (simple_comparison) (simplify (cmp (convert1?@2 addr@0) (convert2? addr@1)) (with { poly_int64 off0, off1; tree base0, base1; int equal = address_compare (cmp, TREE_TYPE (@2), @0, @1, base0, base1, off0, off1, GENERIC); } (if (equal == 1) (switch (if (cmp == EQ_EXPR && (known_eq (off0, off1) || known_ne (off0, off1))) { constant_boolean_node (known_eq (off0, off1), type); }) (if (cmp == NE_EXPR && (known_eq (off0, off1) || known_ne (off0, off1))) { constant_boolean_node (known_ne (off0, off1), type); }) (if (cmp == LT_EXPR && (known_lt (off0, off1) || known_ge (off0, off1))) { constant_boolean_node (known_lt (off0, off1), type); }) (if (cmp == LE_EXPR && (known_le (off0, off1) || known_gt (off0, off1))) { constant_boolean_node (known_le (off0, off1), type); }) (if (cmp == GE_EXPR && (known_ge (off0, off1) || known_lt (off0, off1))) { constant_boolean_node (known_ge (off0, off1), type); }) (if (cmp == GT_EXPR && (known_gt (off0, off1) || known_le (off0, off1))) { constant_boolean_node (known_gt (off0, off1), type); })) (if (equal == 0) (switch (if (cmp == EQ_EXPR) { constant_boolean_node (false, type); }) (if (cmp == NE_EXPR) { constant_boolean_node (true, type); }))))))) and (for minmax (min max) cmp (lt gt) (simplify (minmax (convert1?@2 addr@0) (convert2?@3 addr@1)) (with { poly_int64 off0, off1; tree base0, base1; int equal = address_compare (cmp, TREE_TYPE (@2), @0, @1, base0, base1, off0, off1, GENERIC); } (if (equal == 1) (if (minmax == MIN_EXPR) (if (known_le (off0, off1)) @2 (if (known_gt (off0, off1)) @3)) (if (known_ge (off0, off1)) @2 (if (known_lt (off0, off1)) @3))))))) and address_compare is a fairly large routine and uses equal_address_to which is another quite large routine and we'd need to redo big chunks of that code in constexpr.c. Not using match.pd and fold-const.cc at all during constexpr evaluation (except perhaps for folding of builtins) seems like a nice ultimate goal (we would only optimize what we are required to and nothing else, at least in the strict modes), but I'm afraid it would take several years to implement. Having another flag next to folding_initialize that would be used in fold-const.c in the meantime looks fine to me, any suggestion on how to call it? Jakub