[PATCH] [InstCombine] Propagate non-null facts to call parameters
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. :)
>> EMAIL PREFERENCES
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
> EMAIL PREFERENCES
More information about the llvm-commits