[llvm-commits] [llvm] r73222 - /llvm/trunk/lib/Transforms/IPO/MergeFunctions.cpp

Nick Lewycky nicholas at mxc.ca
Fri Jun 12 06:30:44 PDT 2009


Duncan Sands wrote:
> Hi,
> 
>>>> Emit thunks.
>>> is this a workaround for not all targets supporting
>>> aliases?
>> It's a workaround to make sure "(void*)&F == (void*)&G" doesn't break; if this 
>> wasn't done F and G couldn't be merged because it would change the value of that 
>> expression.
> 
> if F and G are now the same, is there something wrong with changing the
> value of the expression?  Also, why not make use of an alias?

The effect of calling F is the same as the effect of calling G. The 
trouble is that someone may be depending on the fact that the two 
functions have different addresses for correctness.

An alias has the address of the aliasee, so a statement of "if (F == G)" 
which was false before would before true after the transform. Any 
externally visible function could have its address taken, and any 
internal function has F->hasAddressTaken() called on it before deciding 
it's safe to use an alias.

Also, there's a lot of linkage types that the verifier won't allow you 
to put on an alias, so unless it's one of the three whitelisted ones we 
emit a thunk instead.

Nick



More information about the llvm-commits mailing list