https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
It almost looks like a costing issue. The threaders find opportunities to
thread all the incoming edges in the key block to the path which avoids the
call.. But all the paths get rejected.
This is the key block:
;; basic block 11, loop depth 0, count 976284897 (estimated locally, freq
0.9092), maybe hot
;; prev block 10, next block 12, flags: (NEW, REACHABLE, VISITED)
;; pred: 10 [99.8% (guessed)] count:225266786 (estimated locally,
freq 0.2098) (TRUE_VALUE,EXECUTABLE)
;; 14 [100.0% (guessed)] count:751018112 (estimated locally,
freq 0.6994) (TRUE_VALUE,EXECUTABLE)
# o.10_11 = PHI <&m(10), o.10_28(14)>
_17 = o.10_11 == &n;
_20 = o.10_11 == &m;
_27 = _20 | _17;
if (_27 != 0)
goto <bb 6>; [58.87%]
else
goto <bb 12>; [41.13%]
It's pretty obvious that 10->11 can thread to 6. If we look at the other
incoming edge we need o.10_28 which comes from bb14 with the value &n. So that
path should be 14->10->11 threading to 6.
But they get rejected during threadfull2.
