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? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits