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

Pete Cooper peter_cooper at apple.com
Tue Jul 14 09:49:49 PDT 2015


> On Jul 13, 2015, at 10:46 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Mon, Jul 13, 2015 at 10:29 PM Pete Cooper <peter_cooper at apple.com <mailto: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 <mailto: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 wouldn’t blame you, AA looks like fun :)
> 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.
Thanks.  I do appreciate the write-up.  I didn’t think you were immediately taking on the task of stateful AA but thought it best to understand exactly what is being proposed short/long-term.
>  
> 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.
Excellent.  Thanks.
> 
> 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.
I haven’t looked in to this at all, so feel free to shoot it down.  How extensive is AA let alone stateful AA in -O0/1 or some backends via llc?  My thinking is that would it be possible to move any of those to the new PM without doing any more AA work?  -O0 for example really just needs to hook in to NoAA for example which is stateless.  That would give us adoption of the new PM much sooner on those workloads and then we can incrementally add what is needed for -O2, etc.

Cheers,
Pete
> 
> -Chandler

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


More information about the llvm-dev mailing list