[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Chandler Carruth]

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>