From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 99CC4385700A for ; Sat, 19 Jun 2021 17:05:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99CC4385700A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=inria.fr IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AMqewGKmBLhIyKMemJlOgxTMeGnjpDfI93DAb?= =?us-ascii?q?v31ZSRFFG/Fw9vre/sjzuiWetN98YhsdcJW7VpVoIkmslqKdg7NxAV7KZmCPhI?= =?us-ascii?q?LrFuFfBODZrAEIdReSysdW385bH5RDNA=3D=3D?= X-IronPort-AV: E=Sophos;i="5.83,285,1616454000"; d="scan'208";a="385559684" Received: from 85-171-189-19.rev.numericable.fr (HELO hippo) ([85.171.189.19]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2021 19:05:00 +0200 Date: Sat, 19 Jun 2021 19:05:00 +0200 (CEST) From: Marc Glisse To: Richard Biener cc: Victor Tong , "gcc-patches@gcc.gnu.org" Subject: Re: [EXTERNAL] Re: [PATCH] tree-optimization: Optimize division followed by multiply [PR95176] In-Reply-To: Message-ID: <1e409dd-c5a8-a59f-d7ba-86ae805ab54f@hippo.saclay.inria.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, 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-List-Received-Date: Sat, 19 Jun 2021 17:05:04 -0000 On Fri, 18 Jun 2021, Richard Biener wrote: >> Option 2: Add a new pattern to support scenarios that the existing nop_convert pattern bails out on. >> >> Existing pattern: >> >> (simplify >> (minus (nop_convert1? @0) (nop_convert2? (minus (nop_convert3? @@0) @1))) >> (view_convert @1)) I tried to check with a program when T3 x; T1 y; (T2)x-(T2)((T1)x-y) can be safely replaced with (T2)y >From the output, it looks like this is safe when T1 is at least as large as T2. It is wrong when T1 is unsigned and smaller than T2. And when T1 is signed and smaller than T2, it is ok if T3 is the same type as T1 (signed then) or has strictly less precision (any sign), and not in other cases. Note that this is when signed implies undefined overflow and unsigned implies wrapping, and I wouldn't put too much faith in this recently dusted program. And it doesn't say how to write the match.pd pattern with '?', "@@", disabling it if TYPE_OVERFLOW_SANITIZED, etc. Mostly, I wanted to say that if we are going to go handle more than nop_convert for more than just 1 or 2 easy transformations, I think some kind of computer verification would be useful, it would save a lot of time and headaches. (I just check by brute force all possible precisions (from 1 to 6) and signedness for T1, T2 and T3, all possible values for x and y, compute the before and after formulas, accepting if there is UB before, rejecting if there is UB after (and not before), and manually try to see a pattern in the list of types that work) -- Marc Glisse