<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 13, 2015, at 10:46 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jul 13, 2015 at 10:29 PM Pete Cooper <<a href="mailto:peter_cooper@apple.com" class="">peter_cooper@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Firstly, thanks for the detailed update on this...</div><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 13, 2015, at 7:59 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>> wrote:</div><br class=""><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">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.</span></div></blockquote></div></div><div style="word-wrap:break-word" class="">‘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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">Yep. Trust me, I'm not happy about this, and its something I think about a lot.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I’d like to see us try get the new PM enabled before increasing the surface area any more.</div></div></blockquote><div class=""><br class=""></div><div class="">Just to clarify, I'm not working on AA because I want to. =] </div></div></div></div></blockquote>I wouldn’t blame you, AA looks like fun :)<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">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.</div></div></div></div></blockquote>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.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote>Excellent. Thanks.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote>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.</div><div><br class=""></div><div>Cheers,</div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">-Chandler</div></div></div>
</div></blockquote></div><br class=""></body></html>