[llvm-commits] Function aliases

[Chris Lattner]

>> I don't think that really makes sense.  Aliases aren't really global
>> variables or functions themselves, they are a third kind of object.
> Why the third? They definitely *are* either external functions or GVs.
> For example, function aliases can be called, we can take address of
> them, etc. The only difference is absence of body (because they are
> "external") and two symbols they're emitting.

I disagree.  They *act like* functions or GV's, but they really  
aren't them.  For example, (from m understanding), it is not legal to  
give an alias a function body or a global variable initializer.

They clearly need to be usable as a global object (f.e. in a call  
instruction or a load instruction), so they should derive from  
GlobalValue, but they are not themselves functions or global variables.

>> What do you think about making a new GlobalAlias class, which derives
>> from GlobalValue.

> And after subdivide into FunctionAlias & GlobalVariableAlias? This  
> will
> lead to code duplication, since almost all methods of Functions should
> go to FunctionAlias, the same for GVs.

No, you wouldn't need both classes, just a single one.

> This will also require to
> carefully check all other places, where GVs and Functions are used and
> change corresponding logic. Considre for example CallInst. For it we
> should at least resolve issue with getCalledFunction(), which nowadays
> return Function* and we should probably add new method called
> getCalledFunctionAlias() or resolved the two possible return type  
> issues
> otherwise. I don't think it's worth to do so invasive changes  
> everywhere
> for such small feature.

Two things: getCalledFunction already returns null if the callee is  
not a function, e.g. an indirect call.  All of the users of this  
method will already do the right thing and treat aliases as unknown  
calls.  This will be correct.

However, I think that linker should try to resolve aliases when  
possible.  For example, consider something like this:

void foo() {}
void bar()  alias foo

void baz() {  bar(); }

I'd expect the linker (or something else) to want to resolve through  
aliases if the alias, if the actual destination function is around.   
If this happens, in practice, there will be very few (if any) direct  
users of the alias object.

-Chris