[LLVMdev] Re: gcc like attributes and annotations

[Reid Spencer]

On Wed, 2006-03-01 at 13:41 -0600, Chris Lattner wrote:
> On Fri, 24 Feb 2006, Reid Spencer wrote:
> > In thinking about the "right" way to do this, I came up with the idea of
> > a single "blob" of data that could be appended to a Module. This single
> > "annotation" would always be ignored by LLVM, would not require
> > significant additional space to construct,
> 
> If you're talking about a blob of binary data, which does not have 
> "pointers" into the LLVM code, this is fine.  However, there is no reason 
> it needs to be stored "in" the BC format.  It can live "next" to it in the 
> same file without impacting the bc format.

That's what I meant .. just a chunk after the BC content (BC=Module).

As for pointers .. was thinking about exposing slot numbers or something
so you can get a handle on values.

> 
> > and there is already a
> > mechanism for constructing the information via the bytecode reader's
> > handler interface (might need some extension).
> 
> Not clear.  If you're having "pointers" from the blob into the LLVM code 
> (which I believe you would need for it to be useful), then the compiler 
> code that manipulates the LLVM IR has to be aware of these pointers, must 
> be able to update them when it makes changes, etc. This is extremely 
> nontrivial: exactly the same problem as full fledged annotations.

Yeah, I'm not sure either. I was just thinking that the Handler
interface could be used to expose the constructs being parsed ..
however, on deeper reflection, that is only called on *reading* and not
at all on *writing* .. so there goes that idea.

> 
> Additionally, the LLVM linker would have to know how to merge these blobs 
> of data (simple concatenation would be fine, more complex things probably 
> not).

Yeah, concatenation is fine.

> 
> > (JIT/storage/etc).  The only question is: how do multiple tools avoid
> > collision in this approach. Some kind of registry or partitioning of the
> > data could likely solve that.
> 
> Also an issue.

Yup.

> 
> -Chris
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060301/f30dbdf3/attachment.sig>