[LLVMdev] Re: gcc like attributes and annotations
reid at x10sys.com
Wed Mar 1 15:03:44 PST 2006
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the llvm-dev