<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 16, 2015 at 6:30 AM John Criswell <<a href="mailto:jtcriswel@gmail.com">jtcriswel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Dear Chandler,<br>
      <br>
      A few questions:<br>
      <br>
      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?<br></div></div></blockquote><div><br></div><div>Yes, that is the general plan.</div><div><br></div><div>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.</div><div><br></div><div>Explicitly writing manager passes allows the domain and use cases to precisely dictate how extensions in that domain interact.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <br>
      2) Will AliasAnalysis passes still chain as they do today?<br></div></div></blockquote><div><br></div><div>There will definitely be a delegation path.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <br>
      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?<br></div></div></blockquote><div><br></div><div>Yes and no.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <br>
      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.<br></div></div></blockquote><div><br></div><div>I would plan for them to disappear, and soon.</div><div><br></div><div>The entire concept is extremely poorly founded. Look at the this-pointer-adjustment hacks. =/</div><div><br></div><div>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.</div><div><br></div><div>-Chandler</div></div></div>