[llvm-commits] Function aliases

[Reid Spencer]

I've lost track of this dicsussion because it has occurred over so many
emails. Could we please put this into a bugzilla so that it is all in
one place? There is a bugzilla for this alias feature, right?  If not,
Anton, please create one and summarize the various arguments that are
being made here. We shouldn't be having design meetings in
llvm-commits :)

Reid.

On Sat, 2007-04-21 at 14:21 +0400, 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.
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> 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?
>