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