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.
Details
- Reviewers
chandlerc pete nlewycky - Commits
- rGc25df1161456: Reapply 239795 - [InstCombine] Propagate non-null facts to call parameters
rGdfc29fba6035: [InstCombine] Propagate non-null facts to call parameters
rL239849: Reapply 239795 - [InstCombine] Propagate non-null facts to call parameters
rL239795: [InstCombine] Propagate non-null facts to call parameters
Diff Detail
Event Timeline
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
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.
Nick, Pete - I'd like to go ahead and land this. Can I can a formal LGTM from one of you?
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. |
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
Please use "opt -S -instcombine < %s" so that it doesn't emit a ModuleID comment with the filename.