On Thu, Jun 24, 2021 at 6:24 PM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > > On 6/23/2021 4:19 PM, apinski--- via Gcc-patches wrote: > > From: Andrew Pinski <apin...@marvell.com> > > > > To move a few things more to match-and-simplify from phiopt, > > we need to allow match_simplify_replacement to run in early > > phiopt. To do this we add a replacement for gimple_simplify > > that is explictly for phiopt. > > > > OK? Bootstrapped and tested on x86_64-linux-gnu with no > > regressions. > > > > gcc/ChangeLog: > > > > * tree-ssa-phiopt.c (match_simplify_replacement): > > Add early_p argument. Call gimple_simplify_phiopt > > instead of gimple_simplify. > > (tree_ssa_phiopt_worker): Update call to > > match_simplify_replacement and allow unconditionally. > > (phiopt_early_allow): New function. > > (gimple_simplify_phiopt): New function. > So the two questions on my end are why did we restrict when this could > run before and why restrict the codes we're willing to optimize in the > early phase? Not an ACK or NAK at this point, just trying to understand > a bit of the history.
I've done this because jump threading likes to see the CFG structure and some of the testcases use if () return 0/1 which are prone to be value-replaced by phiopt. At the point I added the early phiopt I didn't want to go and fixup all the testcases to avoid the phiopt transforms nor did I want to investigate the "real" impact on code - the purpose of early phiopt was exactly to get min/max/abs replacement done so that was the way of least resistance ... I'd rather not revisit this decision as part of the match-and-simplify series but of course if anyone dares to do the detective work she'll be welcome. Richard. > > jeff >
