Hi,
I'm trying to annotate certain functions in C code, and do something with
these functions in my LLVM pass. I annotate the C code like this:
int __attribute__((annotate("annot"))) function() {
This nicely gets added to the LLVM bitcode in an
@llvm.global.annotations global. Now I had hoped that it'd be easy to
extract
a list of functions annotated with my annotation using
AnnotationManager::getID("annot")
and later on:
function->getAnnotation(AnnotID).
This does not seem to work, unfortunately. Is this supposed to work in this
way, or am I using the wrong functions? I could of course just try to
manually parse the @llvm.global.annotations constant, but that seems rather
tiresome :-)
Thanks,
Bart Coppens
> I'm trying to annotate certain functions in C code, and do something with > these functions in my LLVM pass. I annotate the C code like this: > > int __attribute__((annotate("annot"))) function() { > > This nicely gets added to the LLVM bitcode in an > @llvm.global.annotations global. Now I had hoped that it'd be easy to extract > a list of functions annotated with my annotation using > > AnnotationManager::getID("annot") > and later on: > function->getAnnotation(AnnotID). > > This does not seem to work, unfortunately. Is this supposed to work in this > way, or am I using the wrong functions? I could of course just try to > manually parse the @llvm.global.annotations constant, but that seems rather > tiresome :-)There is no way to get it from the Function*. You have to get the global annotations array and parse it yourself. You could easily write a pass to do this for you and store it in a map. I think the main reason is that we don't want to bloat the IR by making space for annotations in the Function itself. -Tanya
On Thursday 05 June 2008 21:04, Tanya M. Lattner wrote:> There is no way to get it from the Function*. You have to get the global > annotations array and parse it yourself. You could easily write a pass to > do this for you and store it in a map.Ok, I will do that. In this context, is it possible that the code in lib/Transforms/IPO/InlineSimple.cpp has bitrotted somewhat? "Noinline" seems to reside in @llvm.global.annotations as well, but the code doesn't look like it is designed to handle that.> I think the main reason is that we don't want to bloat the IR by making > space for annotations in the Function itself.Right. I had just hoped that even though the link is not explicit in the IR, it would have been preprocessed anyway (given the existence of AnnotationManager). Bart
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 similar. 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? Gr. Matthijs -------------- 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>
On Jun 25, 2008, at 6:33 AM, Matthijs Kooijman wrote:> Hi all,Howdy Matthijs,> 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.Ok, cool. Annotations are tricky to do right :)> 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?).Yes, we should document it. It is a convention established by the __builtin_annotate function in the c compilers. We should standardize it and document it.> 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.Yes, this is a really old mechanism that we should rip out. MachineFunction should be moved to be an analysis that is preserved as an actual part of the passmanager, instead of being a thing we tack onto the Function object. We have killed all uses of this old annotation mechanism except MachineFunction.> Still, it seems that using the AnnotationManager to make the IR > annotations > accessible seems like a decent approach.I agree that *having* an annotationmanager makes sense, but the existing one should die and be replaced. :)> 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).Makes sense. This is similar to how the MachineDebugInfo stuff deserializes debug info out of the LLVM IR and presents it for easy consumption of the code generator.> 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.I think we need to distinguish between two forms of annotation: 1. there are some "annotations" like "readonly", "nounwind", etc that are baked into the LLVM IR and are/should be documented in LangRef. 2. There are annotations that are really "cheap extensions" of the LLVM IR that are either experimental, very domain specific, or that are just metadata about the code. For #1, the current "parameter attributes" we have work reasonable well, and Devang is actually cooking up a proposal to extend them a bit (to fix some issues with LTO). #2 is something that llvm.annotate handles reasonable well, but I agree it would be great to have a nice interface to update/read them. The advantage of #1 is that the compiler as a whole knows about the attributes, but this means that adding one is "hard". The advantage of #2 is that they are easy to add, but they have limitations and can impact codegen (e.g. they disable IPO in some cases).> 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 > similar.It could also be served by making them completely string based, and just provide a simple string interface? That way you don't need classes for each attribute. -Chris
Hi all I have a project where LLVM annotations could be very useful. My current understanding of LLVM in general is still limited, hence a nice interface to annotations or sample code that uses annotations would help me to get started. I was wondering what happened to the proposal for a better interface to handling of annotations, which has been discussed in this thread back in July. Has this proposal lead to any results yet? Best regards, Christian On 25.06.2008, at 15:33, Matthijs Kooijman wrote:> 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 > similar. > > 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? > > Gr. > > Matthijs > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev