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

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>

On Mon, Jun 15, 2015 at 6:43 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
> 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.
>
>
Or 4.1) make it explicit " ... != AR_NoAlias"

David


> Thoughts?
>
> -Chandler
>
> [1] Here is the completely untested sketch of what seems required:
> https://ghostbin.com/paste/2bso6
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__ghostbin.com_paste_2bso6&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=tMIE5SQLfEa0hUI9YbH4c71yOy4s_EqRC15W1Nv9ZiI&s=vnRI8GjnUFpxG_ojZFw0FIkbyK_dtUFCixtvV3YnJug&e=>
>
>
>
> 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
>>
>
> _______________________________________________
> 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/20150615/13bd36e0/attachment.html>

On Mon, Jun 15, 2015 at 7:04 PM Xinliang David Li <xinliangli at
gmail.com>
wrote:
> On Mon, Jun 15, 2015 at 6:43 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
>> 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.
>>
>>
> Or 4.1) make it explicit " ... != AR_NoAlias"
>
How is this different from 2? You *always* have to write 'AliasResult::'
before 'NoAlias'.

>
> David
>
>
>
>> Thoughts?
>>
>> -Chandler
>>
>> [1] Here is the completely untested sketch of what seems required:
>> https://ghostbin.com/paste/2bso6
>>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__ghostbin.com_paste_2bso6&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=tMIE5SQLfEa0hUI9YbH4c71yOy4s_EqRC15W1Nv9ZiI&s=vnRI8GjnUFpxG_ojZFw0FIkbyK_dtUFCixtvV3YnJug&e=>
>>
>>
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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/f9cfa889/attachment.html>

On Mon, Jun 15, 2015 at 6:43 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
> 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.
>
+1 for 3)

-- Sean Silva

>
> 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
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__ghostbin.com_paste_2bso6&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=tMIE5SQLfEa0hUI9YbH4c71yOy4s_EqRC15W1Nv9ZiI&s=vnRI8GjnUFpxG_ojZFw0FIkbyK_dtUFCixtvV3YnJug&e=>
>
>
>
> 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
>>
>
> _______________________________________________
> 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/20150615/2ed87c92/attachment.html>

FYI, I've implemented the plain ol' enum approach in
http://reviews.llvm.org/D10495 -- so far, the alternatives haven't been
compelling to me.

On Mon, Jun 15, 2015 at 7:55 PM Sean Silva <chisophugis at gmail.com>
wrote:
> On Mon, Jun 15, 2015 at 6:43 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
>> 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.
>>
>
> +1 for 3)
>
> -- Sean Silva
>
>
>>
>> 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
>>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__ghostbin.com_paste_2bso6&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=tMIE5SQLfEa0hUI9YbH4c71yOy4s_EqRC15W1Nv9ZiI&s=vnRI8GjnUFpxG_ojZFw0FIkbyK_dtUFCixtvV3YnJug&e=>
>>
>>
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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/20150617/4ec6c9a2/attachment.html>