[LLVMdev] RFC: A plan for stateful alias analysis in LLVM

[Chandler Carruth]

On Mon, Jul 13, 2015 at 10:29 PM Pete Cooper <peter_cooper at apple.com> wrote:

> Firstly, thanks for the detailed update on this...
>
> On Jul 13, 2015, at 7:59 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> Ok, those are all the thoughts I have currently about AA, and where I'm
> headed. This should hopefully provide context for some of the upcoming
> patches.
>
> ‘Headed’ w.r.t. to the new pass manager specifically, or AA in both old
> and new pass managers?  ‘Upcoming patches’ makes it sound like this is
> coming soon so will likely be before the new PM is the only PM.
>
> TBH i’m worried about the surface area we have to debug for
> correctness/performance issues when it comes time to adopt the new pass
> manager.
>
> The new pass manager by design is going to lead to different behavior.
> Analyses will be preserved and invalidated in different orders from old to
> new PMs leading to differences in behavior of transform passes.  Bugs will
> be found in transforms themselves as a result of the new PM ultimately
> (indirectly) giving them different code.  All of this is going to take time
> to debug and block adoption of the new PM.
>

Yep. Trust me, I'm not happy about this, and its something I think about a
lot.

I’d like to see us try get the new PM enabled before increasing the surface
> area any more.
>

Just to clarify, I'm not working on AA because I want to. =] I mean, I'm
enjoying it, but I'm *only* doing what is on my critical path of getting
the new PM working. For example, I wrote this email specifically because
Hal encouraged me to write it up prior to proceeding with refactorings to
remove the update API and establish the core APIs that will work with the
new pass manager.


> Removing the bad AA updating code was fine as we still have the same AA
> updating behavior between old/new (i.e., no AA updating).  But I think
> adding new AA API should be done either in both PMs or neither (for now).
> For one thing, we can’t have enough confidence that the code is working
> correctly if it only works in the new PM which isn’t yet being exposed to
> as much code as the old PM.  Unit tests can only do so much as we can have
> confidence that the AA API is good with a unit test, but its harder to have
> confidence that a transform is calling it correctly without lots of code
> going through the transform pass.
>
> Bugs in transforms related to AA updating will likely be extremely subtle
> and its better to have a blame list as short as possible.  That can only
> happen if the AA code is running on the bots or else we may not catch it
> until the new PM is adopted.
>

Preaching to the choir. I tried to make my opening clarify this. I'm not
planning on adding any special functionality for updating until the new
pass manager is firmly in place precisely because the greater divergence
between the two, the worse the transition will be.

Here, I'm just trying to give an idea of the structure I'm imagining that
will allow us to *eventually* do the update thing. The APIs I'll need to
introduce to get minimal functionality with the new pass manager will
actually go a long way down this path (we'll need FunctionAAManager etc) so
I think Hal was right that I need to lay out this context before doing
stuff. But I plan to do exactly is little as I can get away with until
there is a reasonable baseline entirely based on the new PM.

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