On Wed, 15 Oct 2014, Richard Biener wrote: > Caveat2: the GENERIC code-path of match-and-simplify does > not handle everything fold-const.c does - for example > it does nothing on operands with side-effects - foo () * 0 > is not simplified to (foo(), 0). It also does not > get the benefit from "loose" type-matching by means of > the STRIP_[SIGN_]NOPS fold-const.c performs on operands > before doing its pattern matching. This means that > when I remove stuff from fold-const.c there may be > regressions that are not anticipated (in frontend code > and for -O0 only - with optimization the pattern should > apply on GIMPLE later). > > So - are we happy to lose some oddball cases of GENERIC > folding? (hopefully oddball cases only...)
I don't see any problems with the side effects case; that seems much better only handled on GIMPLE. It seems more plausible something could depend on STRIP_[SIGN_]NOPS calls. -- Joseph S. Myers jos...@codesourcery.com
