[PATCH] [InstCombine] Propagate non-null facts to call parameters

Philip Reames listmail at philipreames.com
Mon May 11 15:22:27 PDT 2015


After thinking about this further and getting most of the way through an alternate implementation in FunctionAttr, I've come to the conclusion that FunctionAttr.cpp is not the right place for this.

For nonnull argument attributes, you have two separate inference problems to solve:

- If the callee provably dereferences or otherwise consumes a pointer in a way which implies it can't be null, you can propagate this outwards.  This is a natural fit for FunctionAttr.cpp since it works bottom up.
- If all callers pass non-null values and the definition is private linkage, the function argument can be assumed to be non-null.  This is inherently a top-down problem in that you need to have visited the callers before visiting the callees.

(In an ideal world, these two would run together and iterated to a fixed point.  Let's assume we're not doing that for the moment.)

The current patch is arguably part of the second inference problem not the first.  It doesn't implement the interprocedural part of the analysis - though arguably, that's what the specialization logic in InlineCost is doing - but it's solving the top down part of the problem.  FunctionAttr.cpp (which is inherently bottom up) isn't really a good fit for this.

Now, InstCombine isn't really a great fit either - it's still run in a bottom up manner by the SCCCallGraphPass when inlining - but that's more of an implementation detail than an inherent part of the pass.  As a practical matter, InstCombine will also get one chance to visit all functions before inlining begins.  FunctionAttr doesn't get this chance, so even locally obvious non-null pointers couldn't be exploited without actually running analysis in the caller rather than relying on the call site attributes.

p.s. While looking into this, I ended up mostly implementing the returns-nonnull bottom up analysis mentioned above.  I'll post that for review separately.


http://reviews.llvm.org/D9132

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list