[LLVMdev] Using annotation attributes

Matthijs Kooijman matthijs at stdin.nl
Wed Jun 25 06:33:48 PDT 2008

Hi all,

I've also been developing an interest in using IR annotations for my compiler.
Some discussion with Bart turns out that he has implemented some code to parse
the llvm.globals.annotations array, but in no way integrated or reusable.
We've spent some thought about how this could be done properly, which I will
share here.

Firstly, however, I was wondering about the format of the
llvm.globals.annotations array. It does not seem to be defined in the LLVM
language reference, shouldn't it be? It's name suggests that it is a reserved
variable name with a fixed type (similar to intrinsic functions?).

Furthermore, it seems that the AnnotationManager that is currently implemented
is capable of keeping a list of Annotations for any Annotatable (currently
only Function). These annotations are kept in memory only and really have
nothing to do at all with the annotations in the IR.

Still, it seems that using the AnnotationManager to make the IR annotations
accessible seems like a decent approach.

The way I see this is having some pass, or probably the assembly reader or the
AnnotationManager itself, parsing the llvm.global.annotations variable and
adding annotations to the corresponding GlobalValues. This would just leave the
annotations in the IR as well, so that transformation passes would properly
preserve them (and, just like debug info, sometimes be prevented from
modifying some annotated global values unless they are taught how to preserve
the annotations).

By using a subclass of Annotation (say, GlobalAnnotation) we can distinguish
between annotations that are (or should be) in the IR and (the existing)
annotations that should be in memory only. This would also allow for newly
added annotations to be immediately be added to the IR, ensuring that the
AnnotationManager's view remains consistent with the IR.

In this way, any annotations added will be implicitely output when the IR is
outputted, without any special support on the output end.

A problem I could imagine using this approach would be name conflicts. Since
any annotation name could come from the IR, these could conflict by the other
names already in use (such as "CodeGen::MachineFunction" IIRC). This could be
solved by using a "GlobalAnnotation::" prefix for the name, or something

A completely alternative approach would be to just use a global map to
facilitate annotation lookups, not using AnnotationManager at all. I can see a
couple of drawbacks here. Firstly, it's a bit confusing that AnnotationManager
would not handle IR annotations. Some decent comments and/or renaming could
sovle that. Secondly, there is a speed gain from using AnnotationManager.
Because annotations are stored at the Annotatable in question, instead of in a
global map, annotations can be retrieved quickly. Also, annotations names are
mapped onto integers, allowing for even faster comparisons and lookups.

So, any thoughts?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080625/bf31c2dd/attachment.sig>

More information about the llvm-dev mailing list