[Bug tree-optimization/102983] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

amacleod at redhat dot com gcc-bugzilla@gcc.gnu.org
Thu Oct 28 16:35:35 GMT 2021


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102983

--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
This is a bit more interesting.
The IL starts the pass as

 <bb 5> :
  if (c_3 < b_4)
    goto <bb 6>; [INV]
  else
    goto <bb 9>; [INV]

  <bb 6> :
  if (c_3 != 0)
    goto <bb 7>; [INV]
  else
    goto <bb 8>; [INV]

<...>
  <bb 11> :
  # c_3 = PHI <0(2), c_2(10)>
  # b_4 = PHI <0(2), b_16(10)>
  if (b_4 <= 0)
    goto <bb 3>; [INV]
  else
    goto <bb 12>; [INV]

so the initial condition is "if (c_3 < b_4)"
the initial attempt to calculate c_3 = PHI flows along and uses a value of b_4
determined by loop analysis of [0,1].  (we haven't gotten to propagating b_4
along the back edges yet)  so it ends up deciding c_3 has a range of [-INF, 1]
We then plod along, and eventually handle b_4, and propagate that b_4 is [0,0[
on the edge 11->3.

There is no direct dependency between c_3 and b_4, so there are no values going
stale due to this updated value.

Meanwhile, we eventually visit the if (c_3 < b_4) stmt, and b_4 is known to be
0, so the simplifier changes this to if (c_3 < 0). 

Ranger however, doesnt know this was simplified, and at the moment doesn't
think it needs to recalculate any outgoing ranges and update on-entry cache
values in successor blocks. It dDoesn't realize there is a reason to
recalculate it.

Whenever we successfully fold or simplify a conditional, we probably need to
check if any values should then be propagated.  I believe that it will happen
automatically for anything that is defined by the statement due to the nature
of the temporal cache.  Statements like GIMPLE_COND which have no LHS have no
triggers.


More information about the Gcc-bugs mailing list