https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
--- Comment #17 from Jeffrey A. Law <law at redhat dot com> ---
Couldn't this be seen as a failure to thread jumps? In the rs676361 testcase
we have the following relevant blocks after DOM2:
;; basic block 2, loop depth 0
;; pred: ENTRY
aOldItem = getitem (); [return slot optimization]
aNewItem_19 = 0;
_9 = MEM[(bool *)this_4(D)];
if (_9 != 0)
goto <bb 3>;
else
goto <bb 4>;
;; succ: 3
;; 4
;; basic block 3, loop depth 0
;; pred: 2
aNewItem$8_22 = MEM[(const long unsigned int &)this_4(D) + 8];
aNewItem$8_20 = aNewItem$8_22;
aNewItem_21 = 1;
;; succ: 4
;; basic block 4, loop depth 0
;; pred: 3
;; 2
# aNewItem_24 = PHI <1(3), 0(2)>
# aNewItem$8_23 = PHI <aNewItem$8_22(3), aNewItem$8_6(D)(2)>
_5 = MEM[(bool *)&aOldItem];
_10 = ~_5;
_11 = VIEW_CONVERT_EXPR<const bool>(aNewItem_24);
_12 = ~_11;
if (_10 == _12)
goto <bb 5>;
else
goto <bb 7>;
;; succ: 5
;; 7
;; basic block 5, loop depth 0
;; pred: 4
if (_10 != 0)
goto <bb 7>;
else
goto <bb 6>;
;; succ: 7
;; 6
;; basic block 6, loop depth 0
;; pred: 5
_13 = MEM[(const long unsigned int &)&aOldItem + 8];
aNewItem$8_14 = aNewItem$8_23;
iftmp.4_15 = _13 == aNewItem$8_23;
_16 = ~iftmp.4_15;
_17 = (int) _16;
;; succ: 7
The key here is that we know the value of _12 depending on how we reach block
#4. If BB4 then transfers control to block #5 we'll also know the value of _10
which would allow us to thread jumps and I believe simplifies things enough to
avoid the false positive, at least on the reduced case. I haven't tried case
from Sergey yet.
This appears to be caused by a few deficiencies in jump threading. None appear
to be major issues though.
