<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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>
      <br>
      2) Will AliasAnalysis passes still chain as they do today?<br>
      <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>
      <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>
      <br>
      Regards,<br>
      <br>
      John Criswell<br>
      <br>
      On 6/13/15 2:52 AM, Chandler Carruth wrote:<br>
    </div>
    <blockquote
cite="mid:CAGCO0Kg7-_amgJF3ViU9fNhTJQuRcOuRyCB7prorpV0KEZ4CHg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">Greetings all,
        <div><br>
        </div>
        <div>I'm working on refactoring the alias analysis layers to
          remove the usage of analysis groups and make the logic
          sharable between old and new pass managers, and I have a
          couple of questions below.</div>
        <div><br>
        </div>
        <div>As background, the overall plan that I've discussed with
          Hal and a few others previously is as follows:</div>
        <div>- Create an AliasAnalysisManager which is provided by a
          normal analysis pass.</div>
        <div>- Use type erasure to register classes which conform to the
          core AliasAnalysis concept with the AliasAnalysisManager.</div>
        <div>- The concept will consist solely of the virtual methods
          currently on AliasAnalysis -- all the helpers and such will
          just be directly provided by the manager layer.</div>
        <div><br>
        </div>
        <div>This will make the AA infrastructure look much like the TTI
          infrastructure, but much simpler as the AA interface boundary
          is actually a reasonable and small concept.</div>
        <div><br>
        </div>
        <div>As part of this, there won't be any inheritance
          relationship between alias analyses, and so the nested enums
          currently in the AliasAnalysis base class aren't a great way
          of describing the return types of these interfaces. I'd like
          to lift them out to be proper top-level enums that describe
          various aliasing and mod-ref information. In some ways, I
          think this is cleaner, especially for mod-ref information
          which might reasonably be used in interfaces that aren't
          precisely that of AA. Any concerns so far?</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Ok, provided you're happy with this, I'd like to ask what
          names and naming conventions people like. Here is a straw-man:</div>
        <div><br>
        </div>
        <div>enum class AliasKind {</div>
        <div>  NoAlias = 0,</div>
        <div>  MayAlias,</div>
        <div>  PartialAlias,</div>
        <div>  MustAlias</div>
        <div>};</div>
        <div><br>
        </div>
        <div>I find the "Alias" suffix redundant, but "No", "Maybe",
          "Partial", and "Must" also seem awkward. Is there a better
          enum name than "AliasKind"? These aren't *just* results, so I
          don't like the current name.</div>
        <div><br>
        </div>
        <div>Whatever convention we use, we should use a similar one for
          the ModRef stuff. ModRefBehavior there already seems to have
          good names if it were switched to an enum class outside of AA.
          ModRefResult I would probably make ModRefKind, but maybe
          ModRefInfo? We call the methods getModRefInfo....</div>
        <div><br>
        </div>
        <div>Please suggest patterns that you like!</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cs.rochester.edu_u_criswell&d=AwMD-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=wJMM0tXPAspyE7osaYubV7b2pGMiskI1ASVDa8zU8qs&s=wlx4tS3miZPWMB3OEfwdP2fizVEhHs0UaJ_vxDNR5nA&e=">http://www.cs.rochester.edu/u/criswell</a></pre>
  </body>
</html>