<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 06/13/2015 12:52 AM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0Kg7-_amgJF3ViU9fNhTJQuRcOuRyCB7prorpV0KEZ4CHg@mail.gmail.com"
type="cite">
<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>
I would mildly prefer that the current (or similar) element names
are kept. A lot of the literature talks about may alias and must
alias relationships, so I'd prefer to stick with consistent and
known terminology. I'm specificly worried about the readabity of
code in places like MemoryDependenceAnalysis and GVN for newcomers
to the community. <br>
<br>
AliasKind::Must is less clear to me than AlaisKind::MustAlias. The
second is admittedly more verbose, but that's not always a bad
thing. <br>
<br>
<br>
<blockquote
cite="mid:CAGCO0Kg7-_amgJF3ViU9fNhTJQuRcOuRyCB7prorpV0KEZ4CHg@mail.gmail.com"
type="cite">
<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>
<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>
</body>
</html>