[Bug rtl-optimization/97603] Failure to optimize out compare into reuse of subtraction result

2021-09-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97603

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/97603] Failure to optimize out compare into reuse of subtraction result

2020-10-28 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97603

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization
   Last reconfirmed||2020-10-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Richard Biener  ---
I guess it could be formulated as code-hoisting opportunity when we make
a - b (or b - a) anticipated on the edges from the a != b compare.  What's
then missing is transforming

  int tem = a - b;
  if (a != b)
 ...

into

  tem = a - b;
  if (tem != 0)

but IIRC we essentially do the reverse transform via match.pd.  Here
the main issue is that the GIMPLE IL doesn't reflect what targets
usually do, that is, flags registers are not modeled and instead we
branch on the actual compare rather than its outcome and a subtract
doesn't set flags.

Eventually this is sth for RTL if-conversion though where those details
are exposed.