similar to: [LLVMdev] Annotate attribute

Hi Tanya, In the long term, how are different uses of this string going to be kept from conflicting? Is this going to introduce another mini-syntax into LLVM, to allow different passes to recognize which pass the string is intended for, or to allow passes to pull out selected substrings and ignore the rest? Dan On Mon, Jun 18, 2007 at 04:44:54PM -0700, Tanya M. Lattner wrote: > > Many of

> In the long term, how are different uses of this string going to be > kept from conflicting? Is this going to introduce another mini-syntax > into LLVM, to allow different passes to recognize which pass the string > is intended for, or to allow passes to pull out selected substrings and > ignore the rest? I am also curious to know what this is intended for precisely.

> 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

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

Hi Timo, congrats to the merger with OX. Currently the implementation of RFC 5257, ANNOTATE-EXPERIMENT-1, has only low priority on http://wiki2.dovecot.org/Roadmap I want to explain a scenario that would benefit from annotation support to - maybe - increase the priority in your roadmap: I'm currently working on a project to publish bank customer related documents inside a banking

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

Hello everyone, I am able to work very well with annotations in C/C++, by using __attribute__((annotate("MYANNOTATION"))) static int a; . Inside the LLVM bytecode I have @llvm.global.annotations and @llvm.var.annotation. However, I was trying to test annotations also in Java, with VMKit. These are the commands that I run: javac -Xlint -g -O Main.java ../Release+Asserts/bin/vmjc Main

Hello Harris, Thank you for your answer. So it is there a way of annotating variables in Java Code, so I can see them into LLVM bytecode? Thank you ! On Mon, Jun 17, 2013 at 3:54 PM, Harris BAKIRAS <h.bakiras at gmail.com> wrote: > Hello Alexandru, > > No you did nothing wrong. > > We are using our own data structure to describe annotations in J3. So it > is normal

Hello Alexandru, No you did nothing wrong. We are using our own data structure to describe annotations in J3. So it is normal that you can not see your Java annotations inside the LLVM bytecode produced. If I remember well, our implementation of annotations do not rely on LLVM annotations. Regards, Harris Bakiras On 06/17/2013 02:19 PM, Alexandru Ionut Diaconescu wrote: > Hello

> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > Cool! I really like the idea. I left a comment about metadata preservation below. > Once this is available we will certainly employ it to understand OpenMP programs better. That sounds like a great use case! Having multiple different uses cases during the bring-up would be very helpful to

Calling an instruction a "source" is basically another way to say "we can't dataflow through this". What I'm trying to say is that this is not really a property of the instruction type. I agree we should be adding annotations sparingly - that is, we should not annotate something we can infer. But that's a semantic property, so I don't really see why that means

What classpath implementation are you using ? GNUClasspath or OpenJDK ? Harris Bakiras On 06/17/2013 03:57 PM, Alexandru Ionut Diaconescu wrote: > Hello Harris, > > Thank you for your answer. So it is there a way of annotating > variables in Java Code, so I can see them into LLVM bytecode? > > Thank you ! > > > On Mon, Jun 17, 2013 at 3:54 PM, Harris BAKIRAS

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

Hi, it seems that Squirrel mail uses Mailbox annotations for storing Expire times on the Server. It's an Cyrus server currently. (I've no clue how cyrexpire is able to read it's information from the annotiations) Does dovecot support some similiar mechanism? Or - does anybody know anything about how it's supposed to work on Cyrus and how it can be emulated/simulated with dovecot?

> On Nov 9, 2020, at 19:27, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > On 11/9/20 5:09 AM, Florian Hahn wrote: >> >>> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com <mailto:johannesdoerfert at gmail.com>> wrote: >>> >>> Cool! I really like the idea. I left a comment about metadata preservation

On 1/1/19 12:20 PM, Richard W.M. Jones wrote: > Should we use attribute((nonnull)) at all? There's a very interesting > history of this in libvirt -- try looking at commit eefb881 plus the > commits referencing eefb881 -- but it does seem to work for me using > recent GCC and Clang. > > I only did a few functions because annotating them gets old quickly... For internal

On 12/16/2016 11:37 AM, Michael Kuperstein wrote: > Calling an instruction a "source" is basically another way to say "we > can't dataflow through this". > > What I'm trying to say is that this is not really a property of the > instruction type. > I agree we should be adding annotations sparingly - that is, we should > not annotate something we

On Fri, Dec 16, 2016 at 11:49 AM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/16/2016 11:37 AM, Michael Kuperstein wrote: > > Calling an instruction a "source" is basically another way to say "we > can't dataflow through this". > > What I'm trying to say is that this is not really a property of the > instruction

The general idea to date has been only "sources" get annotations. If there's something we fundamentally *can't* analyze through, that's where we annotate. We try not to use annotations for places where we could have but didn't. e.g. call metadata/attributes allow us to model external calls, load metadata allow us to model frontend knowledge of external memory

Based on the earlier comments in this thread and the existence of a transform that adds 'nonnull' to callsite params, I have proposed a patch to extend nonnull to a parent function: https://reviews.llvm.org/D27855 ...but given today's comments about inferring the analysis rather than making it part of the IR, this might be the wrong approach? On Fri, Dec 16, 2016 at 12:49 PM, Philip