llvm dev - Jun 2015 - [LLVMdev] AliasAnalysis refactoring for the new pass manager

> On 2015-Jun-13, at 09:12, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 
> 
> On Sat, Jun 13, 2015 at 12:52 AM, Chandler Carruth <chandlerc at
gmail.com> wrote:
> Greetings all,
> 
> 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.
> 
> As background, the overall plan that I've discussed with Hal and a few
others previously is as follows:
> - Create an AliasAnalysisManager which is provided by a normal analysis
pass.
> - Use type erasure to register classes which conform to the core
AliasAnalysis concept with the AliasAnalysisManager.
> - 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.
> 
> 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.
> 
> 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?
> 
> 
> Ok, provided you're happy with this, I'd like to ask what names and
naming conventions people like. Here is a straw-man:
> 
> enum class AliasKind {
>   NoAlias = 0,
>   MayAlias,
>   PartialAlias,
>   MustAlias
> };
> 
> 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.
> 
> AliasRelationship? None, May/PossiblyAliased/Unknown, Aliased,
PartiallyAliased?
> 
> (tense could use some tweaking and I suppose this still has the suffix
problem in all except the "None" case... )
I like this colour:

    enum class AliasKind /* or AliasCategory? */ {
      Null,
      Unknown,
      Partial,
      Complete
    };

> 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....
> 
> Please suggest patterns that you like!
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Mon, Jun 15, 2015 at 3:56 PM Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
> I like this colour:
>
>     enum class AliasKind /* or AliasCategory? */ {
>       Null,
>       Unknown,
>       Partial,
>       Complete
>     };
>
So, the only non-bikeshed-color argument I have (which is also referenced
by Philip, but i couldn't reply to both) suggests we *really* want NoAlias,
MayAlias, and MustAlias, because these are terms of art in the literature
(confirmed by DannyB who is a reasonable expert in alias analysis
literature). I'm inclined to keep these names as a consequence. The natural
extension is PartialAlias.

That leaves the question of the enumeration name. I think
"AliasResult" is
my new found favorite. Danny gave me a reason: these are really results of
a particular query, not just abstract kinds of aliasing... And its shorter
than AliasRelationship. =]

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150615/7b071f44/attachment.html>

> On 2015-Jun-15, at 16:29, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> On Mon, Jun 15, 2015 at 3:56 PM Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
> I like this colour:
> 
>     enum class AliasKind /* or AliasCategory? */ {
>       Null,
>       Unknown,
>       Partial,
>       Complete
>     };
> 
> So, the only non-bikeshed-color argument I have (which is also referenced
by Philip, but i couldn't reply to both) suggests we *really* want NoAlias,
> MayAlias, and MustAlias, because these are terms of art in the literature
(confirmed by DannyB who is a reasonable expert in alias analysis literature).
I'm inclined to keep these names as a consequence. The natural extension is
PartialAlias.
Sad that "alias" is sometimes a noun and sometimes a verb, but if
it's in the literature, then I guess that's that.

Might be better to have "NoAlias" be the only one that treats
"alias"
as a noun though.  PartiallyAlias?  PartlyAlias?  (But since it's
inconsistent anyway, then PartialAlias isn't all bad.)
> That leaves the question of the enumeration name. I think
"AliasResult" is my new found favorite. Danny gave me a reason: these
are really results of a particular query, not just abstract kinds of aliasing...
And its shorter than AliasRelationship. =]
> 
> Thoughts?
I don't really see how it's better than AliasKind, but I don't see
anything wrong with it either.