[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