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

[Pete Cooper]

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.

I’d like to see us try get the new PM enabled before increasing the surface area any more.  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.

Thanks,
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/123872ad/attachment.html>