LFTR and SCEV interact badly on the following test case:
%gep = getelementptr inbounds i8, i8* %base, i64 %iv %cnd1 = icmp ne i8* null, %gep br i1 %cnd1, label %latch, label %exit
SCEV will happily compute an exit count for this, but does so disregarding the inbounds annotation. As a result, we end up with a integer comparison of the following form:
%cnd1 = icmp ne i64 %iv, -1 * (ptrtoint(p)) br i1 %cnd1, label %latch, label %exit
Once we've done that, we delete the GEP, and loose the inbounds fact. At that point, we're stuck.
As somewhat of a hack, this patch implements a special case rule to discharge the null check before LFTR has a chance transform it. I don't really like this solution, but after a fair amount of thought, I can't come up with anything better which isn't either a) just as much of a special case, or b) a huge amount of complexity.
(For context, the reported compile time regression happens purely because we end with a loop which "more analyzeable" after LFTR (11 occurrences), and other transforms go to town. We never discharged the check at all - in either form -, and in the faster case just left the loops unoptimized. This special case appears to address the slowdown on this example.)