[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Chandler Carruth]

On Tue, Jun 16, 2015 at 6:30 AM John Criswell <jtcriswel at gmail.com> wrote:

>  Dear Chandler,
>
> A few questions:
>
> 1) Are you removing the analysis groups functionality?  If so, will the
> new way to get similar functionality be to write a Manager pass like
> AliasAnalysisManager?
>

Yes, that is the general plan.

The analysis group infrastructure was used exceedingly rarely, and each of
the uses had a subtly different desired interaction between the extension
points it managed.

Explicitly writing manager passes allows the domain and use cases to
precisely dictate how extensions in that domain interact.

Naturally, if we end up producing repeated patterns here, we should extract
common helper functionality so that producing these manager passes isn't
unnecessarily repetitive.


> 2) Will AliasAnalysis passes still chain as they do today?
>

There will definitely be a delegation path.

I've not actually implemented it yet, so its a bit premature, but my
general plan was to try to clean up and formalize several aspects such as
the concept of TBAA only refining MayAlias pointers, leaving MustAlias
pointers alone.


> 3) Will your refactoring fix the "problem" (or maybe it's a feature?) of
> having to manually schedule AliasAnalysis passes because pass invalidation
> always causes the default AliasAnalysis pass from the group to be scheduled
> by the PassManager?
>

Yes and no.

It won't be a problem because there won't be any "default" scheduling. The
entire manager will get invalidation events and get to handle them as it
sees fit.

But it will still be a complication as the manager will have to handle
invalidation in some reasonable way for a stateful AA implementation. I'm
going to try to wire everything up such that a stateful AA would Just Work,
but there may be rough edges until someone really exercises the
infrastructure. If I don't have time to dig into this fully, I'm hopeful
that George or whomever next works on CFL-AA will push it forward because
CFL in particular should benefit heavily from being able to have some state
but to also have controlled invalidation of the state.


>
> We have some old code that, if we resurrect it, will need to be rewritten
> if Analysis Groups are removed.  Removing/Replacing Analysis Groups is
> fine, but I'd like to know in advance if they disappear.
>

I would plan for them to disappear, and soon.

The entire concept is extremely poorly founded. Look at the
this-pointer-adjustment hacks. =/

Long term, I expect almost all users will look like TargetTransformInfo
(but hopefully with a *much* smaller interface!) and be able to follow its
pattern to produce a simple analysis which is constructed with the
type-erased implementation desired.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/d3ea35aa/attachment.html>