https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #48 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 30 May 2022, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 > > --- Comment #47 from Hongtao.liu <crazylht at gmail dot com> --- > > > > > The issue is that the re-association pass doesn't handle operations > > with undefined overflow behavior, we do have duplicate bugreports > > for this. > > > > I saw below in match.pd > > 478/* Combine successive multiplications. Similar to above, but handling > 479 overflow is different. */ > 480(simplify > 481 (mult (mult @0 INTEGER_CST@1) INTEGER_CST@2) > 482 (with { > 483 wi::overflow_type overflow; > 484 wide_int mul = wi::mul (wi::to_wide (@1), wi::to_wide (@2), > 485 TYPE_SIGN (type), &overflow); > 486 } > 487 /* Skip folding on overflow: the only special case is @1 * @2 == > -INT_MIN, > 488 otherwise undefined overflow implies that @0 must be zero. */ > 489 (if (!overflow || TYPE_OVERFLOW_WRAPS (type)) > 490 (mult @0 { wide_int_to_tree (type, mul); })))) > > Can it be extend to (mult (plus_minus (mult @0 INTEGER_CST@1) INTEGER_CST@3) > INTEGER_CST@2), so at least we can handle it under -fwrapv? With -fwrapv the reassoc pass might do this already (not sure with mixing multiplication and addition, you'd have to try). But sure, we could add a pattern for the above (with appropriate single-use handling).
