[llvm-commits] [cfe-commits] [PATCH][RFC] PR10367: don't allow GlobalAlias's aliasee to be an arbitrary Constant
Duncan Sands
baldrick at free.fr
Mon Aug 1 02:34:20 PDT 2011
Hi Jay,
>>>> Since we have to accept bitcasts and geps of globals as alias operands,
>>>> is there any point in allowing the result type to be different to the
>>>> operand type?
>>>
>>> It saves creating a bitcast ConstantExpr where none is needed.
>>
>> LLVM has a very regular type system. By introducing alias as a special
>> exception where types don't have to match you make LLVM IR less regular
>> which is bad.
>
> It sounds like you are arguing against PR10367:
>
> "Instead, the initializer of a
> GlobalAlias should be required to be a GlobalValue, but the type of the source
> and dest of the alias should not be required to be the same, they should just
> be completely decoupled."
>
> ... not against my implementation of it.
that's correct. It seemed like a good idea at first, but once you see that
RAUW means you need to retain bitcasts and GEPs as alias operands, 99% of the
interest of the idea goes away in my opinion.
That said, your patch simplifies the way global aliases are manipulated by
users, right? Do you think you can keep the ease-of-use improvements while
discarding the IR modification parts?
>> For the sake of saving a few bitcasts you are increasing
>> the number of concepts: "entities must not be multiplied beyond necessity".
>
> My patch removes code from the verifier. I think this is evidence that
> it doesn't complicate the rules for LLVM IR, it simplifies them.
It creates an exception to a general IR rule for no real gain, and that is bad.
Getting rid of code in the verifier is nice but not enough to justify changing
the IR in my opinion.
Ciao, Duncan.
More information about the llvm-commits
mailing list