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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D4609#835270, @haicheng wrote:

> In https://reviews.llvm.org/D4609#833428, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D4609#801397, @haicheng wrote:
> >
> > > Hi Hal,
> > >
> > > I am wondering what's your plan of this patch?  I am particularly interested in the propagation of noalias attributes.
> >
> >
> > I've not thought about this in a while, but I'd certainly like to see this functionality. Aside from some refactoring, it needs two things:
> >
> > 1. The noalias inference needs to be updated to be correct. The easiest way to do this is, instead of actually doing an alias check on the arguments, to call GetUnderlyingObjects and check for disjoint sets of *identified* underlying objects (still checking for capturing, and possibly restricting to local identified objects unless we can do a global capture check). Any set that is disjoint from the others means that its associated argument can be marked as noalias.
> > 2. I'd like to revisit how the iteration is done and how this fits with the rest of the pass manager. While it does naturally iterate top down, and the CGSCC pass manager normally iterates the other way, there should be a way to put this logic into the part of the pipeline that is iterating with the inliner. I was never satisfied with the idea that we'd only do this once at the beginning of the pipeline. Now that we have a new pass manager, we can think about how this might work in that framework as well. Also, the new pass manager should make it more natural to get a per-function dominator tree, etc. @chandlerc, thoughts on how this might best be done?
> >
> > > Thank you,
> > > 
> > > Haicheng
>
>
> That is great.  I rebased your code and replaced the alias check with cheking distinct sets of underlying objects.  It is working for most benchmarks of llvm-test-suite and spec20xx.


It occurs to me that the need for this might be removed by another potential improvement (suggested to me by Chandler at EuroLLVM this year): We can make CGSCC analysis wrapper for our current analysis passes in order to allow these analyses to look back through function arguments into the function's callers. To make this work, we'd:

1. Make CGSCC analysis passes corresponding to our current analysis passes. For example, AA, ValueTracking, etc. (I realize that ValueTracking is not really an analysis pass right now, and while we might want to change that at some point, I don't think it matters for this description).
2. These pass accept analysis queries and produce results by looking at the calling functions and calling the function/local analysis on the values at each call site, and then intersecting the results. If there are too many call sites, or unknown call sites, then you need to give up.
3. Provide these CGSCC analysis handles to the corresponding local analyses so that, as they do a recursive analysis, when they hit arguments, then can call into the CGSCC analyses to continue the analysis into the callers.

If we did  that, do you think we'd still need this transformation?


https://reviews.llvm.org/D4609