[PATCH] Top-Down FunctionAttrs propagation for noalias, dereferenceable and nonnull inference

[Hal Finkel]

----- Original Message -----
> From: "Nick Lewycky" <nlewycky at google.com>
> To: "Chandler Carruth" <chandlerc at google.com>
> Cc: "reviews+d4609+public+b1f539b8c63822a5" <reviews+D4609+public+b1f539b8c63822a5 at reviews.llvm.org>, "Commit
> Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Monday, July 21, 2014 10:21:30 PM
> Subject: Re: [PATCH] Top-Down FunctionAttrs propagation for noalias,	dereferenceable and nonnull inference
> 
> 
> 
> 
> 
> On 21 July 2014 19:46, Chandler Carruth < chandlerc at google.com >
> wrote:
> 
> 
> 
> 
> 
> 
> 
> On Mon, Jul 21, 2014 at 7:31 PM, Nick Lewycky < nlewycky at google.com >
> wrote:
> 
> 
> 
> On 21 July 2014 17:08, hfinkel at anl.gov < hfinkel at anl.gov > wrote:
> 
> 
> Use isDereferenceablePointer (which checks things like argument's
> dereferenceable attribute) in addition to using
> isSafeToLoadUnconditionally (which is mostly useful for its local
> instruction scan). Also fixed up one of the test cases.
> 
> 
> 
> The iteration order of the functions within an SCC is
> non-deterministic and may result in different attributes being added
> depending on pointer comparison. Consider the case of two leaf
> functions sharing the same parent, then add call edges between those
> two "leaf" functions. The df iteration may visit either of those two
> first, and if one of them depends on the attributes on the other,
> but the other does not, then you have an order dependence.
> Would iterating to fix-point within an SCC be a reasonable solution?
> 
> 
> It would be correct but wouldn't necessarily fit in O(n^2) time.
> 
> 
> There is an efficient fix, it's just time consuming to implement. For
> a per-function attribute, look at the (function call graph) SCC and
> determine their attributes as a group, by checking whether any of
> the functions would fail to have the attributes even if all the
> others did have the property. If they all would have the attribute
> when the others do, mark them all as having it. Otherwise, the only
> way each of them has the attribute is if you could prove it to have
> the attribute you're looking for even when the other functions in
> the SCC do not.
> 
> 
> You can do this with a local scan of each function up front, breaking
> them down into a) clearly gets attribute regardless of attributes on
> other in-SCC functions b) clearly does not get attribute regardless
> of attributes on other functions c) could get the attribute if the
> other in-SCC functions do too. You can apply the attribute to
> anything in category a) immediately, then everything in category c)
> gets the attribute only if nothing fell into category b.
> 
> 
> The dereferencable attribute is not a per-function property, it's a
> per-argument property, so to handle this you'd need to build up an
> SCC graph of the arguments. Note that you end up with a forest while
> scc_iterator requires a connected graph, so in my implementation I
> add a "synthetic root node", but after that point the rest of the
> reasoning is the same. I added this to FunctionAttrs.cpp in r147327,
> if it helps to see an implementation:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111226/134114.html

Nick,

Just to be clear, all of the attributes this pass handles are parameter attributes, and they all depend exclusively on properties of the state at the call site, not on the function itself.

Given that the df_iterator ordering won't be stable for SCCs, I now understand the motivation of the SCC iterators ;) -- but when you "time-consuming to implement", I suppose you mean that I'd need to hook every analysis being used to be able to provide delayed decisions based on attributes within the same SCC?

Do you know what would be involved in getting the 'Inverse' SCC iterators to work? Then I could walk top-down, and at least do a fixed-point iteration within each SCC so that the answers would be deterministic (even if not optimal).

Regarding optimality, I might be able to speculate the attributes within each SCC to get the optimal answer (meaning setting it in the most optimistic way, then performing the analysis, and then removing it if we can't prove it otherwise correct).

Thanks again,
Hal

> 
> 
> Nick
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory