[llvm-commits] Function aliases

[Chris Lattner]

On Apr 21, 2007, at 3:21 AM, Anton Korobeynikov wrote:
> Hello, Chris.
>> 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.
> After stripping alias target they are nothing more than just external
> declarations. That's why I'm thinking it's just GV or Function plus
> small addendum.

It is more restricted than a function, and also applies to a global  
though.

>> No, you wouldn't need both classes, just a single one.
> But function aliases can, for example, definitely have CC. It acts  
> like
> normal Function.

How, why?  I don't see why an alias would have a calling convention.   
What would it be used for?


>> 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.
> But it's not indirect call. getCalledFunction() should return  
> "function
> part" of function alias.

Why?  What client of getCalledFunction would that benefit?  If the  
aliased-to callee is already available there would be no reference to  
the alias in any call.

>> I'd expect the linker (or something else) to want to resolve through
>> aliases if the alias, if the actual destination function is around.

> This seems to be useful feature. However, usually aliases are  
> introduces
> when no alias target exists in the current module.

Sure, but when the LLVM linker runs, it can resolve them.

> I think the best solution is the one submitted by Gordon:
>
> 1. Introduce new table (or use some current) in the Module for alias
> targets.
> 2. User normal Function's and GV's for aliases. They will be just
> external function/variable *declarations*. Everything will be ok.
> 3. Add methods addAlias(), removeAlias() to GV class to add/remove
> entries to alias target table. +some utility functions to deal with  
> this
> table during e.g. object destruction/copying.
> 4. Let Verifier to reject that GV's and Functions, which has
> initializer/body and entry in the alias target table.
> 5. AsmParser should reject usage of alias and initializer/body as  
> well.
> 6. Let Linker to "propagate" alias targets, if possible.
> 7. During codegen query alias target entry for each  
> MO_ExternalSymbol to
> check, whether there is any alias. And emit needed code.
>
> Sounds better?

I don't see how this is any better than just adding an explicit list  
of GlobalAliases.

-Chris