[LLVMdev] AliasAnalysis refactoring for the new pass manager
Xinliang David Li
xinliangli at gmail.com
Mon Jun 15 19:04:28 PDT 2015
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>
More information about the llvm-dev
mailing list