>> 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
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
