https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68844
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-12-11
Ever confirmed|0 |1
--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
So there's 4 potential jump threads as we enter the first DOM pass. Before the
change in question, all 4 would be threaded.
After the change, we record just two threads and only actually realize one jump
thread. So what happened?
One of the two recorded jump threads is explicitly dropped. The block in
question originally looks like:
<bb 18>:
# kill_elt_40 = PHI <kill_elt_13(7), kill_elt_3(5)>
if (b_elt_10(D) != 0B)
goto <bb 10>;
else
goto <bb 14>;
We record a jump thread (7,18); (18,10) as exit block #7. We later proceed to
optimize block 18 to look like:
# kill_elt_40 = PHI <kill_elt_13(7), kill_elt_4(5)>
goto <bb 10>;
(ie, along every path we know that b_elt_10 != 0B)
So we remove the recorded jump thread (7,18); (18,10) -- this is desired
behaviour. So the recorded, but unrealized jump thread is easily explained.
Additionally, by optimizing block #18 like that, we find there's no need to
record the jump thread (5,18); (18,10). Again, desired behaviour.
We have a similar situation arise in another block:
<bb 8>:
if (b_elt_10(D) != 0B)
goto <bb 9>;
else
goto <bb 14>;
We optimize bb8 to look like:
<bb 8>:
goto <bb 14>;
Which eliminates the need for the jump thread (15,3); (3,8)J; (8,14). Very
desirable behaviour as well.
So of the 4 potential jump threads, only 1 is actually still relevant after the
change in question. And it is properly threaded ;-) So everything is doing
exactly what it should and we just need to twiddle the testcase a bit to
reflect current reality.
