https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even when the optimization is restricted to GIMPLE only, the single_use in
there doesn't work really well before fre1 optimizes it, because the above
mentioned testcase doesn't reuse the same expression, but has a different
subtraction that just needs to be CSEd first.
An alternative would be to treat (signed undefined overflow) x >= y and x - y
interchangeably by SCCVN, i.e. hash them the same and if we find both forms (in
either order), transform the x >= y back into (x - y) >= 0 (similar for other
non-equality comparisons). I guess that would fix both that testcase and
PR94798 which also suffers from that:
int
foo (int a, int b)
{
return (b >= a) ? (b - a) : 0;
}
int
bar (int a, int b)
{
return ((b - a) >= 0) ? (b - a) : 0;
}
bar is optimized more than foo - but in this case it is a user that wrote it in
two different forms rather than one.
Another option is to enable the x - y op 0 to x op y canonicalization only
after SCCVN got a chance to CSE stuff after inlining, while that would fix the
por45397.c testcase, it wouldn't the above PR94798 one.
Richi, any thoughts on this?
