[LLVMdev] Re: gcc like attributes and annotations

[Reid Spencer]

Hi Jakob,

I have some thoughts on this too ..

On Fri, 2006-02-24 at 19:56 +0100, Jakob Praher wrote:
> I get you 100 % here. But as you say later in the mail, many information
> is done by some runtime std::map<Value*,foo> stuff. Which is really
> handy at runtime, but I *had* serialization in mind when I was thinking
> about Annotations. I see annotations as a way to serialize some extra
> information with the bytecode without having to extend/change the core
> classes. The best way to implemented in runtime is to use some kind of
> std::map subscripting, plus the additional benefit that you can
> serialize it to the bytecode. Perhaps the best of both worlds.
> 
> Two things here:
> (1) Annotations should not be something which really changes the meaning
> of a Value/Type. All the passes should work without the annotation.
> 
> (2) I think annotations are a handy way to augment the bytecode without
> changing the bytecode format. It gives people the freedom to add some
> extra information. This is also interesting since changing the
> bytecode/adding fields to Value/... is often not a real option since one
> wants to work with production core libraries. (like I do now).
> 
> Perhaps the thing could be solved by adding policy statemetns to
> annotations. I could imagine the inventor of an Annotation should think
> about how the annotation should behave during optimisation/change. So
> the anntation should have a policy field which defaults to DontCare. In
> that case the user of the Annotation cannot be sure that it will get
> retained or something like that.
> 
> Given the discussion that happens in the higher level vms (like Gilad
> Bracha's Paper on pluggable type systems) gives some hints about the
> difficulties in changing Instruction Sets over time. I think core system
> functionality is invariant, but meta information, that is not essential
> for the application to work should be pluggable too.

As Chris mentioned, I would prefer that we keep annotations out of the
core IR altogether as they are fraught with problems that are not easy
to resolve. However, I understand where you're coming from in wanting to
keep additional information with the bytecode. I have wanted the same
thing for use by front end or specialized tools. For example an IDE that
could keep track of source information or a language that needs special
passes that can only be done at link time.

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, and there is already a
mechanism for constructing the information via the bytecode reader's
handler interface (might need some extension).

This is simply a way of making that std::map of information embeddable
in the bytecode. It means the information is stored in one additional
bytecode block (at the end) where it doesn't have any impact on LLVM
(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.

> 
> > As a historical curiosity, Function still needs to be annotatable due to
> > the LLVM code generator relying on it.  This will be fixed in LLVM 1.8
> > and Function will not be annotable anymore.
> > 
> > If you *really* just want per-pass local data, you should just use an
> > std::map from the Value* to your data.
> 
> Why not see Annotations as the means to serialize these Maps. Maybe we
> could add an Annotations table that maps Value types to ConstantPool
> entries or something like that. This would make it more easily for LLVM
> libraries in other languages too.

This is similar to my idea above, but I wouldn't want to restrict it to
any particular data structure. The application can construct the data
however it wishes and simply pass a pointer to a block of memory to the
bytecode writer. 

Reid
-------------- 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/20060224/66b99f11/attachment.sig>