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

[Jay Foad]

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?

Thanks,
Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-globalalias.diff
Type: text/x-patch
Size: 20995 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110728/8a9d67ee/attachment.bin>