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.133.124]) by sourceware.org (Postfix) with ESMTPS id 828163858D37 for ; Thu, 3 Feb 2022 09:33:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 828163858D37 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-112-6zdIYGxMMISYyeH1Sv5Hcw-1; Thu, 03 Feb 2022 04:33:43 -0500 X-MC-Unique: 6zdIYGxMMISYyeH1Sv5Hcw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 25CD4510A8; Thu, 3 Feb 2022 09:33:39 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF51910640E2; Thu, 3 Feb 2022 09:33:38 +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 2139XZAv3861568 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 3 Feb 2022 10:33:35 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 2139XYFM3861567; Thu, 3 Feb 2022 10:33:34 +0100 Date: Thu, 3 Feb 2022 10:33:34 +0100 From: Jakub Jelinek To: Eric Botcazou Cc: Richard Biener , gcc-patches@gcc.gnu.org, Zhao Wei Liew Subject: Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280] Message-ID: <20220203093334.GJ2646553@tucnak> Reply-To: Jakub Jelinek References: <2228044.ElGaqSPkdT@fomalhaut> <612pq5qr-38s3-2767-9os8-q334254n8p5r@fhfr.qr> <11915893.O9o76ZdvQC@fomalhaut> MIME-Version: 1.0 In-Reply-To: <11915893.O9o76ZdvQC@fomalhaut> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: Thu, 03 Feb 2022 09:33:47 -0000 On Thu, Feb 03, 2022 at 10:06:42AM +0100, Eric Botcazou wrote: > > Well, yes, we have to fix it. I will share my thoughts when coming > > along the bugreport. > > IMO we should simply scrap it, as it does not serve any useful purpose, breaks > a very ancient and useful idiom and also introduces an artificial discrepancy > between 1/X and 2/X for example. That doesn't make sense. The optimization can be useful, it doesn't have to be for user written y = 1 / x; but can appear through inlining or some other optimizations, e.g. jump threading and suddenly we have constant 1 in some bb, if it a never executed at runtime block, it will be likely shorter because of the optimization, if it is not, then it will be cheaper. And, this is definitely not the first optimization that assumes undefined behavior in integer division should not happen, lots of other optimizations do the same thing. E.g. consider unsigned foo (unsigned x, unsigned y) { if (x >= 2) return 0; if (x == 1) y += 4; return y / x; } Here the ranger optimizes away the division, in GCC11 in vrp1 pass, in GCC12 in evrp pass already. Even in match.pd I vaguely remember one or two optimizations where it also relied on division by zero being undefined. Jakub