https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
--- Comment #42 from Jeffrey A. Law <law at redhat dot com> ---
Jason, thanks for the testcase in c#41. Here's the blocks of interest:
;; basic block 5, loop depth 0
;; pred: 3
;; 2
# maybe_a$m_6 = PHI <_5(3), maybe_a$m_4(D)(2)>
# maybe_a$4_7 = PHI <1(3), 0(2)>
<L0>:
_8 = maybe_b.live;
if (_8 != 0)
goto <bb 6>; [0.00%]
else
goto <bb 7>; [0.00%]
;; succ: 6
;; 7
;; basic block 6, loop depth 0
;; pred: 5
B::~B (&maybe_b.D.2512.m_item);
;; succ: 7
;; basic block 7, loop depth 0
;; pred: 5
;; 6
maybe_b ={v} {CLOBBER};
resx 3
;; succ: 8
;; basic block 8, loop depth 0
;; pred: 7
<L1>:
_9 = VIEW_CONVERT_EXPR<bool>(maybe_a$4_7);
if (_9 != 0)
goto <bb 9>; [0.00%]
else
goto <bb 10>; [0.00%]
;; succ: 9
;; 10
I believe the complaint arises from the PHI in BB5 which is then used BB9.
Intuitively we can see that anytime BB5 is reached directly from BB2 we know
that BB8 will transfer control to BB10, avoiding the problematical use in BB9.
However, the form of the CFG is particularly difficult for forward threader to
handle. BB5 is a join point. We can only have one other block in the
threading path with side effects -- and unfortunately we have BB6 and BB7. We
can fudge a bit on BB8 due to some work Alex did a couple years back, but
ultimately the forward threader isn't going to handle this.
The backwards threader supports multiple blocks with side effects, but there
can only be one path from the start to the destination. 2->5->6->7->8 and
2->5->7->8 makes two paths, so it gets rejected. This is a limitation we
really should lift in the backwards threader.
I suspect the V_C_E inhibits tree-ssa-uninit.c code to avoid false positives.
If we know the range of the V_C_E operand is narrow enough that it fits into
the type of the result of the V_C_E, could we optimize the V_C_E into a
NOP_EXPR? We'd then forward propagate away the NOP_EXPR and the result is
something the suppression code in tree-ssa-uninit.c can analyze better.
We can see that the path 2->5->6->7->8->9 is infeasible as is the path
2->5->7->8->9. ANytime BB5 is reached directly from BB2
