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! -Chris _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
