This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by reames on Apr 20 2015, 3:49 PM.

Details

Summary

If a parameter to a function is known non-null, use the existing parameter attributes to record that fact at the call site. This has no optimization benefit by itself - that I know of - but is an enabling change for http://reviews.llvm.org/D9129.

Diff Detail

Event Timeline

reames updated this revision to Diff 24070.Apr 20 2015, 3:49 PM
reames retitled this revision from to [InstCombine] Propagate non-null facts to call parameters.
reames updated this object.
reames edited the test plan for this revision. (Show Details)
reames added reviewers: chandlerc, nlewycky.
reames added a subscriber: Unknown Object (MLST).
pete added a subscriber: pete.Apr 20 2015, 3:57 PM

This is somewhat similar to what FunctionAttrs.cpp does, although nonnull is a parameter level instead of function level attribute.

Should this behavior be moved to FunctionAttrs.cpp instead of InstCombine, or vice-versa?

Pete Cooper wrote:

This is somewhat similar to what FunctionAttrs.cpp does, although nonnull is a parameter level instead of function level attribute.

Should this behavior be moved to FunctionAttrs.cpp instead of InstCombine, or vice-versa?

It should probably go into FunctionAttrs.cpp which also computes
per-argument readonly/readnone/nocapture. One of the things to note is
that you can end up with an SCC between functions A and B where they
pass a parameter to each other which has no reason not to be nonnull
except for their mutual use of each other. FunctionAttrs builds up an
SCC graph of Arguments to solve this optimally and deterministically.

Nick

http://reviews.llvm.org/D9132

EMAIL PREFERENCES

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

llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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.

As a follow on to my previous comment, Nick's comment about being able to handle SCCs in one go is completely valid. It's orthogonal to my point, and is out of scope for this patch. As I mentioned previously, this patch doesn't do *any* interprocedural attribute propagation. Adding the SCC aware logic - even if it mostly runs bottom up - would be useful, it's just a different patch.

reames added a comment.Jun 1 2015, 2:03 PM

Nick, Pete - I'd like to go ahead and land this. Can I can a formal LGTM from one of you?

pete accepted this revision.Jun 1 2015, 2:05 PM
pete added a reviewer: pete.

Sorry, shouldn't have done that sooner. LGTM.

This revision is now accepted and ready to land.Jun 1 2015, 2:05 PM
nlewycky accepted this revision.Jun 1 2015, 2:59 PM
nlewycky edited edge metadata.
nlewycky added inline comments.
test/Transforms/InstCombine/nonnull-param.ll
1

Please use "opt -S -instcombine < %s" so that it doesn't emit a ModuleID comment with the filename.

This revision was automatically updated to reflect the committed changes.
pete added a comment.Jun 15 2015, 6:05 PM

Sorry, Phab is acting up for me, hence email.

I think this line should actually set 'Changed = true;’ and not return. That way you can handle more than a single nonnull at a time.

+ return CS.getInstruction();

Otherwise LGTM.

Cheers,
Pete