[LLVMdev] Finding Things In SymbolTable

[Chris Lattner]

On Wed, 7 Jan 2004, Reid Spencer wrote:

<sorry for the delay, things have been crazy here moving between
buildings>

> The SymbolTable is a map of Type* to a map of names to Value*.  This
> means that in order to lookup something by name you first have to know
> what type it is. For the basic types this is fine because you generally
> always know which basic type you're after.  But, for derived types, this
> can be quite complicated. It isn't always possible to know the exact
> type.

Ok, the first thing to realize is that the current symbol table really
can't change in any meaningful way.  The SymbolTable class represents the
_LLVM_ symbol table, which is used to figure out how to print stuff out
and how to resolve references, in an entirely LLVM specific way.  As such,
any changes to the SymbolTable class should be extensions on what we have:
eliminating the current SymbolTable class would break too many ingrained
LLVM semantics.

> The problem is that when I hit the Function definition, all I have is
> "My_Signature" to identify the function's type.  LLVM currently doesn't
> let me find this signature because I'd have to know its type first. The
> whole point of putting it in the symbol table is so that I can look up
> its type later on with only its name.

So there are two possible solutions to this problem.  When you are
actually generating LLVM code it probably makes sense to keep an extra
XPL-specific symbol table on the side, which you use to keep track of the
information that you need.

On the other hand, it might be reasonable to add a simple multimap from
names to LLVM values to the LLVM SymbolTable.  This would be occasionally
useful for things like looking up function names, but would add a serious
amount of bloat to the SymbolTable for something that is infrequently
useful.

> Any thoughts on this?  Am I missing something?

It sounds feasible, but I'm not sure it is something that should be added
to the LLVM SymbolTable class.  This class really isn't meant to be the
"one true solution" for all possible name lookup requests, it's really
meant to support to LLVM core.  Transformations, backends, and front-ends
that need something different should probably build support on top of the
LLVM symbol table stuff to support their needs (e.g., the llvm::Mangler
interface that Brian wrote for the backends).

Is this reasonable?

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/