[llvm-commits] [cfe-commits] [PATCH][RFC] PR10367: don't allow GlobalAlias's aliasee to be an arbitrary Constant

[Jay Foad]

On 29 July 2011 18:33, Chris Lattner <clattner at apple.com> wrote:
>
> On Jul 28, 2011, at 8:48 AM, Jay Foad wrote:
>
>> http://llvm.org/bugs/show_bug.cgi?id=10367
>>
>> To summarise the PR, Chris said that a GlobalAlias's aliasee should
>> always be a GlobalValue (we shouldn't allow arbitrary Constants), and
>> the types of the alias and the aliasee shouldn't be required to match.
>>
>> Duncan pointed out that even if the aliasee is a GlobalValue, anyone
>> could call ReplaceAllUsesWith() and change it into something that is
>> no longer a GlobalValue (but is presumably still a Constant). In my
>> testing I found that this is a real problem: GlobalOpt will do
>> someGlobalValue->replaceAllUsesWith(someBitcastExpression).
>>
>> Here's an attempt to find some middle ground. The idea is to change
>> the API of GlobalAlias so that it looks like the aliasee is always a
>> GlobalValue, but in fact we tolerate operand 0 being a bitcast, which
>> we strip off in getAliasee(). getAliasedGlobal() disappears, because
>> getAliasee() always returns a GlobalValue anyway.
>>
>> There should be no change to the bitcode or textual form of LLVM IR.
>> But I'm a bit concerned that I didn't need to make any changes to the
>> bitcode writer -- maybe "make check" doesn't test it very thoroughly.
>>
>> I didn't understand why GlobalAlias tolerates the aliasee being a
>> getelementptr ConstantExpr, so I did some archaeology, found PR4066,
>> and added a Clang testcase to show that we do still have to handle
>> this. (The reason is, even if you try to create a bitcast,
>> ConstantFold.cpp's FoldBitCast() will sometimes return you a
>> getelementptr instead.)
>>
>> The patch passed "make check-all". Comments?
>
> This patch looks great to me Jay, thanks!

I will check it in after all then, if there are no more objections in
the next couple of days.

Thanks,
Jay.