On 6/25/2021 2:24 AM, Richard Biener wrote:
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.
Thanks for the background. So Andrew is largely just preserving this
property. Works for me. And just to be explicit 4/7 is fine for the
trunk.
jeff
