[PATCH] D64533: [IndVars] Special case the problematic (gep inbounds p, iv == nullptr) problem (pr42357)

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: sanjoy, nikic, nicholas.
Herald added subscribers: javed.absar, bollu, mcrosier.

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.)


https://reviews.llvm.org/D64533

Files:
  lib/Transforms/Utils/SimplifyIndVar.cpp
  test/Transforms/IndVarSimplify/inbounds-gep-null.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D64533.209069.patch
Type: text/x-patch
Size: 11617 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190710/06ce913a/attachment.bin>