On Thu, 26 Nov 2020, Jakub Jelinek wrote: > On Thu, Nov 26, 2020 at 09:24:30AM +0000, Richard Biener wrote: > > > For signed integers with undefined overflow we already optimize x * y / y > > > into x, but for signed integers with -fwrapv or unsigned integers we > > > don't. > > > The following patch allows optimizing that into just x if value ranges > > > prove that x * y will never overflow. > > > It uses the global SSA_NAME_RANGE_INFO only, because like mentioned > > > in another PR we don't currently have a way to tell the ranger from > > > match.pd > > > the use stmt (and we'd need in that case to tell ranger to only follow > > > SSA_NAME_DEF_STMTs + SSA_NAME_RANGE_INFO and never go in the other > > > direction, as following immediate uses seems forbidden in match.pd). > > > Another possibility would be to optimize this during vrp, but on the > > > other side the optimization itself is match.pd-ish. > > > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > Hmm, can't you match > > > > > (div (mult@3:c @0 @1) @1) > > > > and then look at the range of @3 directly? > > No. I need to check whether the multiplication will never overflow, > i.e. I need @3 range in the infinite precision (for multiplication > twice as large precision as the multiplication (when the arguments and > result have the same precision, which is the case for IL MULT_EXPR)), > while the @3 precision is that after wrapping it into the @3's precision. > So, e.g. the multiplication could always overflow, yet the range > wouldn't be VARYING, consider > @0 in [0x4000000, 0x40000ff] and @1 64, then the infinite precision > range would be [0x100000000, 0x100003fc0], but @3 range is > [0, 0x3fc0], etc. What I need to check is essentially that > __builtin_mul_overflow_p (@0, @1, (typeof (@0)) 0) folds to constant 0.
Oops, yes. The patch is OK. Thanks, Richard.
