[LLVMdev] Re: Newbie questions
sabre at nondot.org
Wed Apr 26 17:48:47 PDT 2006
On Wed, 26 Apr 2006, Reid Spencer wrote:
> On Wed, 2006-04-26 at 16:32 -0500, Chris Lattner wrote:
>> I still don't follow. Having annotations on the IR is *exactly*
>> equivalant to having a map from IR objects to the things you want to
>> annotate them with.
>> Why isn't this just as acceptable (and problematic) as annotations?
> Because LLVM doesn't store that map, someone else has to.
> Furthermore, LLVM doesn't assist with the on-disk association. The
> pointers in the map are useless after the IR objects are written to disk
> and the program terminates. LLVM also doesn't have a facility for
> reconstruction of the map when bytecode is read.
LLVM has a symbol table that is persistent across serialization. Ensure
that the annotated objects have a name, and you can find them.
> We've talked about this before and loosely suggested that it might be
> possible to:
> 1. have llvm provide an interface for storing a "blob" at the end
> of a bytecode file. LLVM ignores this blob.
You don't need an llvm interface for this, you can embed the LLVM .bc file
into other bigger tcontainers.
> 2. Augment BytecodeHandler.h to allow for unique identifiers with
> each object being read (it does some of this now).
> 3. Create something like BytecodeHandler for writing so that the
> unique identifiers can be associated with the user's map.
> 4. Leave details of the "blob" construction up to the user.
I don't understand this, but I also don't see why it is necessary. Using
the symbol table should be perfectly acceptable.
Echoing Tom's sentiment: without a specific problem we're trying to solve,
coming up with complex overgeneral solutions is not a useful way to spend
time. I'd much rather spend time analyzing specific concrete problems
that real people are hitting, to come up with the right solution for the
More information about the llvm-dev