similar to: [LLVMdev] [Proposal] Annotated assembly output

How is the client supposed to make use of this markup information? At first glance it seems like client code will just devolve into a pile of regex insanity. Why not use an existing standardized markup, like XML (not that I'm that fond of XML)? At a higher level, why not expose an API for iterating over (potentially annotated) tokens which can be programmatically inspected. So what you expose

Hi Sean, Thanks for the feedback! Exactly the sort of discussion I was hoping to get started. On Oct 12, 2012, at 10:12 AM, Sean Silva <silvas at purdue.edu> wrote: > How is the client supposed to make use of this markup information? Target-independent introspection of the assembly. A simple example is color-coded output in a GUI disassembly display. All registers show up one color,

On Oct 12, 2012, at 1:07 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi Jim, thanks for the response. That pretty much clears up my primary > concern. +1 for keeping the C API small/stable/robust :) > > Having multiple hand-implemented parsers accepting the output, I think > it would be wise to have an official "conformance suite" for the > syntax so that

Hi Jim, thanks for the response. That pretty much clears up my primary concern. +1 for keeping the C API small/stable/robust :) Having multiple hand-implemented parsers accepting the output, I think it would be wise to have an official "conformance suite" for the syntax so that external implementors can sleep more soundly with their implementation; if I were implementing a parser for

Another question: What kind of documentation you are planning to produce for this feature? -- Sean Silva On Fri, Oct 12, 2012 at 4:36 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 12, 2012, at 1:07 PM, Sean Silva <silvas at purdue.edu> wrote: > >> Hi Jim, thanks for the response. That pretty much clears up my primary >> concern. +1 for keeping the C

On 13/10/12 17:24, Sean Silva wrote: > Another question: What kind of documentation you are planning to > produce for this feature? > > -- Sean Silva > > On Fri, Oct 12, 2012 at 4:36 PM, Jim Grosbach<grosbach at apple.com> wrote: >> >> On Oct 12, 2012, at 1:07 PM, Sean Silva<silvas at purdue.edu> wrote: >> >>> Hi Jim, thanks for the

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

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, 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 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

How can they processed? I cant seem to find any solid information about how they exist in IR form from a Passes perspective. I see things like @llvm.var.annotation in dumps but no relevant sounding methods to get at these. Thank you On Thu, Sep 22, 2011 at 1:20 PM, Julien Lerouge <jlerouge at apple.com> wrote: > On Thu, Sep 22, 2011 at 02:46:05AM -0400, Mark Brown wrote: > > With

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 followed http://stackoverflow.com/questions/4976298/modern-equivalent-of-llvm-annotationmanagerin order to get annotations from my target bytecode. All the examples that I give in the following is related to the code from that link. I have `__attribute__((annotate("DS"))) int f=0;` into the target C++ program and the related IR code: @.str = private unnamed_addr

Hi Reid, Reid Spencer schrieb: > I have some thoughts on this too .. > Great! > 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

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

I created a plugin to add simple Annotations to VarDecls and FieldDecls, and write this modified AST out to a file. I notice that when I use clang to compile this file I get different code then when I use the source directly. In both cases I'm compiling with -O4. Can anyone explain this? Thanks define i32 @somefunc(i32 (i32)* %ptr) nounwind uwtable { entry: %ptr.addr = alloca i32 (i32)*,

This is a interesting thread. I think this would also help with compiling scripting languages such as JavaScript/Python etc. We could keep the high level meta data and runtime binding info as language specific bytecode in the file and just have the parts that are easy to represent as compileable in the main object sections. There is no intrinsic reason for all the runtime type information to get

Dear all, I would like to make a large scatter plot created with R available as an interactive web graphic, in combination with additional text-annotations for each data point in the plot. The idea is to present the text-annotations in an HTML-table and inter-link the data points in the plot with their corresponding entries in the table, i.e. when clicking on a data point in the plot, the