[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Chandler Carruth]

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>