On Fri, 2007-04-20 at 22:12 +0400, Anton Korobeynikov wrote: > Gordon, > > > Why not simply reinsert the aliased GV into the symbol table under the > > alias name? In this manner, alias objects would not need to derive > > from GlobalValue at all. Aliases could be stored in a list on the side > > as you describe, solving the memory usage problem. The majority of > > code could remain ignorant of them, > The main problem is that code should not ignore them :(
90% of LLVM *should* ignore them. The only time that they are needed is at codegen time. > Also, they > should be codegen'ed in some funky way, when we're needed both names: > alias and it's target at one place. Right. But, why impose a new concept on all of LLVM just for this very limited code gen situation. I would rather have the CodeGen library simply look for GVars or Functions that have two names. > Such information can be unavailable > if we'll put aliases in the separate table. Certainly the codegen can be augmented to query a separate table. > I don't think, there is some > "direct" way to query symbol table at codegen-level. It could be arrange in SelectionDAGISel.cpp during the lowering. > However, this can > be good idea: to have some module-level map, which stores alias targets. The "module-level map" is just the symtab. When SelectionDAGISel lowers the IR to machine level it just needs to have a way to associate multiple names with a given Function or GVar node. Reid. > _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
