From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id EF5463889829 for ; Mon, 21 Jun 2021 07:08:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF5463889829 Received: by mail-ej1-x635.google.com with SMTP id ji1so20916403ejc.4 for ; Mon, 21 Jun 2021 00:08:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C5cPmR6UenST5Vyg057GCW0+KeYs2mFpmkYwbFbW5l8=; b=nzaqlAoRmgVrnXmgg7rYaeN4qNe3iOIpJJt46x0g573zrlmzqM5thaeZcEtt3HdnvH nCpB74GABn0xt15IHWfeTVnpFK7QINAFZAMlZuttOreeZpY4dWVUQtZKzD49zHNW1pY6 6aQJOC39KRhF6Y7OlorDiZNhb/sXJwuM/0CFcFa9qa73oE2FsmPZSc6Qx6SPQT6yJA7a LVkRRTFRm11rPvamdCpjeJKEn6UK4Z6WTd/89GlKm4rQOvsFOdF1mpepmhOq839wOq1a pBCC6yCpmlKihbPNvIxHXdv0zNF2NuR53Pq378GKFTb+sI1o5IcdoMix0kkdCHMQ2KPn 5TEw== X-Gm-Message-State: AOAM532j+PVI7/wJaTnPIvMNDh9Zq6lWjUdonVPLSHYeA0nvcvPHc/Kr soERsvklzIEYU0MxOi2AmPa/p8fhipU/0M2891I= X-Google-Smtp-Source: ABdhPJwtmQGeYH7JdCF5njp4io6TiskVwmEu1QQXoKM5pJa4Skuf6/hODvCAKIet9ZdN1ThkDVgmMc6RoEAvW1zhaR0= X-Received: by 2002:a17:907:3faa:: with SMTP id hr42mr5844903ejc.129.1624259331976; Mon, 21 Jun 2021 00:08:51 -0700 (PDT) MIME-Version: 1.0 References: <1e409dd-c5a8-a59f-d7ba-86ae805ab54f@hippo.saclay.inria.fr> In-Reply-To: <1e409dd-c5a8-a59f-d7ba-86ae805ab54f@hippo.saclay.inria.fr> From: Richard Biener Date: Mon, 21 Jun 2021 09:08:41 +0200 Message-ID: Subject: Re: [EXTERNAL] Re: [PATCH] tree-optimization: Optimize division followed by multiply [PR95176] To: Marc Glisse Cc: Victor Tong , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: Mon, 21 Jun 2021 07:08:54 -0000 On Sat, Jun 19, 2021 at 7:05 PM Marc Glisse wrote: > > 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. True. I wonder if auto-generating such tests from match.pd rules would be a good project to work on (GSoC?). When there's define_match involved things get a little tricky, but then one item on the TODO list is "inlining" those at the use site (exploding the decision tree even more). Richard. > (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