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