<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 13, 2015 at 12:52 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>AliasRelationship? None, May/PossiblyAliased/Unknown, Aliased, PartiallyAliased?<br><br>(tense could use some tweaking and I suppose this still has the suffix problem in all except the "None" case... )</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>