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

Philip Reames listmail at philipreames.com
Mon Apr 20 17:03:43 PDT 2015

On 04/20/2015 04:04 PM, Nick Lewycky wrote:
> 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.
I have no objection to moving this in FunctionAttr.cpp.  I'm just not 
sure I see the advantages.  In particular, I'm not seeing the case where 
having knowledge of the entire SCC gives us more information.  Just 
because two functions don't pass each other a null pointer doesn't mean 
that someone outside the SCC doesn't.  Am I missing something obvious 
here?  NonNull is somewhat different than readonly in that it documents 
the contract of the caller, not really of the callee*.

Also, we currently don't use ValueTracking from within 
FunctionAttrs.cpp.  Are we okay adding that dependency?  I think the 
answer is yes, just checking.

* Well, as I'm using it right now.  You could perform an entirely 
separate analysis that went looking for loads or stores derived from a 
given pointer which post dominate the function entry to infer that an 
argument "must have been" non-null.  That would a logical SCC based 
formulation, but is distinct from the "caller doesn't pass null" case 
here.  I'm not volunteering to do that work.  :)

> Nick
>> http://reviews.llvm.org/D9132
>>    http://reviews.llvm.org/settings/panel/emailpreferences/
>> _______________________________________________
>>   llvm-commits mailing list
>>   llvm-commits at cs.uiuc.edu
>>   http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> http://reviews.llvm.org/D9132
>    http://reviews.llvm.org/settings/panel/emailpreferences/

More information about the llvm-commits mailing list