https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-06-09
Ever confirmed|0 |1
--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
Thanks Vincent. Glad to have this little test.
AFAICT before the recent jump threading changes we had something like this in
VRP1:
;; basic block 9, loop depth 0, count 0, freq 900, maybe hot
;; prev block 8, next block 10, flags: (NEW, REACHABLE)
;; pred: 5 [50.0%] (FALSE_VALUE,EXECUTABLE)
e_23 = ASSERT_EXPR <e_13(D), e_13(D) >= -52>;
if (e_23 < 0)
goto <bb 10>;
else
goto <bb 11>;
;; succ: 10 [27.0%] (TRUE_VALUE,EXECUTABLE)
;; 11 [73.0%] (FALSE_VALUE,EXECUTABLE)
;; basic block 10, loop depth 0, count 0, freq 243, maybe hot
;; prev block 9, next block 11, flags: (NEW, REACHABLE)
;; pred: 9 [27.0%] (TRUE_VALUE,EXECUTABLE)
e_22 = ASSERT_EXPR <e_23, e_23 < 0>;
_2 = (unsigned int) e_22;
_3 = _2 + 53;
n_16 = (int) _3;
;; succ: 11 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 11, loop depth 0, count 0, freq 900, maybe hot
;; prev block 10, next block 12, flags: (NEW, REACHABLE)
;; pred: 9 [73.0%] (FALSE_VALUE,EXECUTABLE)
;; 10 [100.0%] (FALLTHRU,EXECUTABLE)
# n_9 = PHI <53(9), n_16(10)>
goto <bb 13>;
Note that as written we can pretty easily derive a range for n_16 as [1..52]
which ultimately allows us to remove the block with the out-of-range array
index as unreachable.
With the threading before VRP things are bit more complex as BB10 has 3
predecessors (due to threading). Now it happens that on each predecessor we
have a suitable ASSERT_EXPR to narrow the range of e_13. But we're unable to
use them in that form.
Ideally we'd like to either be smarter about the initial insertion point or
sink them after insertion. I'm pretty sure that would resolve this issue.
However, it's not compile-time friendly. I'm going to need to think a bit more
on this one.
