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

> 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.

>
> Sad that "alias" is sometimes a noun and sometimes a verb, but if
> it's in the literature, then I guess that's that.
Yes, you will see both "a may-alias b" and "a is a may-alias of
b", etc..

So, after looking at *doing* this, I'm left with more questions and no good
answers. C++ has truly failed me today.

This enum is currently designed (and even *documented* as being designed)
to allow conversion-to-bool to detect whether any alias is possible (that
is, only no-alias becomes false). This makes it *really* easy to write the
overwhelming majority of test: if ("do things alias") { bail... }.

It turns out that it is impossible to do this with C++11 "enum
class"es.
Despite the fact that they seemed specifically designed to serve these
kinds of use cases. They are, IMO, completely useless at this point.

It also turns out that it is *nearly* impossible to define a normal class
and a collection of constants that behave in the way folks generally want a
strongly typed enum to behave. It requires class templates, typedefs,
constexpr, and like 3x the boilerplate code. Its nuts.[1]

So the options I see are:

1) Commit the significant body of code necessary to emulate proper enum
classes in C++, and document it as a boilerplate pattern. I might be able
to shrink it with some clever macro tricks, but it looks pretty doubtful
honestly.

2) Use "enum class AliasResult { NoAlias, ... }" and update everywhere
to
say explicitly "... != AliasResult::NoAlias".

3) Use "enum AliasResult { NoAlias = 0, ... }" and everything Just
Works
but we pollute the llvm namespace with "NoAlias" and friends.

4) Use "enum AliasResult { AR_NoAlias = 0, ...}" to get the effect of
#2
with some minimal name collision prevention.

Thoughts?

-Chandler

[1] Here is the completely untested sketch of what seems required:
https://ghostbin.com/paste/2bso6


On Mon, Jun 15, 2015 at 6:27 PM Daniel Berlin <dberlin at dberlin.org>
wrote:
> >
> > Sad that "alias" is sometimes a noun and sometimes a verb,
but if
> > it's in the literature, then I guess that's that.
>
> Yes, you will see both "a may-alias b" and "a is a may-alias
of b", etc..
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/f17749a5/attachment.html>