[LLVMdev] Re: Newbie questions

Chris Lattner 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.

*shrug*

> 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 
problem.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/




More information about the llvm-dev mailing list