https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |19794
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
Ultimately this is a missed jump thread. In vrp1 after insertion of
ASSERT_EXPRs we have:
;; basic block 2, loop depth 0, count 0, freq 1005, maybe hot
;; prev block 0, next block 11, flags: (NEW, REACHABLE, VISITED)
;; pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
if (flag_6(D) == 0)
goto <bb 3>; [33.00%]
else
goto <bb 11>; [67.00%]
;; succ: 3 [33.0%] (TRUE_VALUE,EXECUTABLE)
;; 11 [67.0%] (FALSE_VALUE,EXECUTABLE)
;; basic block 11, loop depth 0, count 0, freq 673, maybe hot
;; prev block 2, next block 3, flags: (NEW)
;; pred: 2 [67.0%] (FALSE_VALUE,EXECUTABLE)
flag_14 = ASSERT_EXPR <flag_6(D), flag_6(D) != 0>;
goto <bb 4>; [100.00%]
;; succ: 4 [100.0%] (FALLTHRU)
;; basic block 3, loop depth 0, count 0, freq 332, maybe hot
;; prev block 11, next block 4, flags: (NEW, REACHABLE, VISITED)
;; pred: 2 [33.0%] (TRUE_VALUE,EXECUTABLE)
flag_13 = ASSERT_EXPR <flag_6(D), flag_6(D) == 0>;
value_10 = get_value ();
;; succ: 4 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 4, loop depth 0, count 0, freq 1005, maybe hot
;; prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;; pred: 3 [100.0%] (FALLTHRU,EXECUTABLE)
;; 11 [100.0%] (FALLTHRU)
# value_12 = PHI <value_10(3), value_7(D)(11)>
;; succ: 5 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 5, loop depth 1, count 0, freq 6700, maybe hot
;; prev block 4, next block 8, flags: (NEW, REACHABLE, VISITED)
;; pred: 4 [100.0%] (FALLTHRU,EXECUTABLE)
;; 9 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE)
;; succ: 8 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 8, loop depth 2, count 0, freq 10000, maybe hot
;; prev block 5, next block 10, flags: (NEW)
;; pred: 5 [100.0%] (FALLTHRU,EXECUTABLE)
;; 10 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE)
_1 = flag_6(D) == 0;
_2 = value_12 != 0;
_3 = _1 & _2;
if (_3 != 0)
goto <bb 10>; [33.00%]
else
goto <bb 6>; [67.00%]
The key is to realize that the path 2->11->8 will always then transfer control
to 6 (because _3 will always have the value zero). If we were to thread that
jump, then the uninitialized use of value_7 would disappear.
I've got some code that I think would pick this up, but I haven't installed it
because it was developed after stage1 close and does not fix any known
regressions.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
[Bug 19794] [meta-bug] Jump threading related bugs
