On 02/06/2017 06:06 AM, Richard Biener wrote:
+ /* If OP0 CODE OP1 is an overflow comparison, if it can be expressed
+ as a simple equality test, then prefer that over its current form
+ for evaluation.
+
+ An overflow test which collapses to an equality test can always be
+ expressed as a comparison of one argument against zero. Overflow
+ occurs when the chosen argument is zero and does not occur if the
+ chosen argument is not zero. */
+ tree x;
+ if (overflow_comparison_p (code, op0, op1, use_equiv_p, false, &x))
This somehow feels like a hack so I'd add a comment why we do not change
the IL in the first place.
It doesn't feel like a hack to me. It's just discovering alternate
ranges/forms for a class of comparisons that are sometimes more useful
than the cananoical form we have in the IL (which promotes
{ADD,SUB}_OVERFLOW detection).
Regardless, a comment WRT why we don't transform the IL sounds quite
reasonable.;
Feeding overflow_comparison_p the original and the swapped comparison
looks like it makes it more expensive given its stmt walking?
No. In both cases we have to walk one or both chains to see if we have
a statement like X +- CST. Then and only then we walk the other chain
to see if it is X.
Identification of X in the other chain can happen at the start of the
chain, end of the chain or somewhere in the middle (and I've seen all
three happen in practice).
If we knew we were going to fully walk both chains, then the answer
would be that we should walk them once to the end, then do detection
both ways on the result of fully walking both chains.
I'd see whether
returning a second output from it (whether we matched op0 or op1) would
simplify callers.
I think it could slightly. Let me play with that.
jeff
