[PATCH 4/7] Allow match-and-simplified phiopt to run in early phiopt
Fri Jun 25 08:24:20 GMT 2021
On Thu, Jun 24, 2021 at 6:24 PM Jeff Law via Gcc-patches
> On 6/23/2021 4:19 PM, apinski--- via Gcc-patches wrote:
> > From: Andrew Pinski <email@example.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
More information about the Gcc-patches