On 10/21/24 3:18 AM, Richard Biener wrote:
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/112418
gcc/ChangeLog:
* tree-ssa-phiopt.cc (is_factor_profitable): New function.
(factor_out_conditional_operation): Add merge argument. Remove
arg0/arg1 arguments. Return bool instead of the new phi.
Early return for virtual ops. Call is_factor_profitable to
check if the factoring would be profitable.
(pass_phiopt::execute): Call factor_out_conditional_operation
on all phis instead of just singleton phi.
* doc/invoke.texi (--param phiopt-factor-max-stmts-live=): Document.
* params.opt (--param=phiopt-factor-max-stmts-live=): New opt.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/factor_op_phi-1.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-2.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-3.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-4.c: New test.
Dregding up all kinds of old memories.
Not terribly happy with the new param, but a magic constant would
probably be even worse.. So I won't object to that.
A heuristic based on GIMPLE stmt placement is quite bad (given TER).
The constant is OK as a compile-time limiter though. The heuristic to
not move across a call looks good - we might want to see whether we
can expose a predicate that identifies "TER barriers"?
I don't even remember what might be "TER barriers". A call is pretty
obvious, but I bet there are others.
I'll also note sinking has similar profitability issues.
Absolutely. Note that I think any time we sink through a PHI we're
likely doing something that isn't well handled by the sinking pass.
It's also something that wasn't well handled by other algorithms I've
looked at in the past. Essentially PHIs were sinking barriers.
It looks like the PHI-OPT heuristic only looks at either the defs or the uses?
It's typically been just one or the other. Which might explain why
changes I played with eons ago in tree-ssa-phiopt never worked out well
in practice.
Jeff
