[cfe-commits] [PATCH][RFC] PR10367: don't allow GlobalAlias's aliasee to be an arbitrary Constant
clattner at apple.com
Fri Jul 29 12:33:59 CDT 2011
On Jul 28, 2011, at 8:48 AM, Jay Foad wrote:
> 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
> 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!
More information about the cfe-commits