search for: annoations

The following is a brief proposal for annotated assembly (and disassembly) output. Kevin Enderby and I have been discussing this a bit and are interested in getting broader feedback from interested folks. LLVM Rich Assembly Output LLVM's (dis)assembly output is currently very raw. Consumers have limited ability to introspect the instructions' textual representation or to reformat for

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

On 03/10/2015 10:14 AM, Diego Novillo wrote: > > > On Thu, Mar 5, 2015 at 11:29 AM, Bob Wilson <bob.wilson at apple.com > <mailto:bob.wilson at apple.com>> wrote: > > >> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com >> <mailto:dnovillo at google.com>> wrote: >> >> On Thu, Feb 26, 2015 at 6:54 PM,

...- AnnotationType - Name NULL values are wildcards. So you could say: Give me all annotations for a Value* /// Function local annotations Value* v = ... vector< const Annotation *> &ans = curFunction->lookupAnnotation( v, NULL, NULL); Or based on a specific type: /// Module wide annoations AnnotationType *type = ... Value< const Annotation *> &ans = module->lookupAnnotation( v, type, NULL ); This just random thought though. > >>>As a historical curiosity, Function still needs to be annotatable due to >>>the LLVM code generator relying on it. This...

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

...t; So you could say: > > Give me all annotations for a Value* > > /// Function local annotations > Value* v = ... > vector< const Annotation *> &ans = curFunction->lookupAnnotation( v, > NULL, NULL); > > Or based on a specific type: > > /// Module wide annoations > AnnotationType *type = ... > Value< const Annotation *> &ans = module->lookupAnnotation( v, type, NULL ); > > This just random thought though. > > > > >>>As a historical curiosity, Function still needs to be annotatable due to > >>>the LLV...

Hi, Using 2.2.9 (ubuntu 14.04 LTS) and sending the following command, the server crashes when I try to delete an annotation: ? login ? C: 2 setannotation Trash "/vendor/cmu/cyrus-imapd/expire" ("value.shared" NIL) Apr 27 09:29:16 backend1 dovecot: imap-login: Login: user=<heiko>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=6651, secured Apr 27 09:29:16 backend1

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 Mar 24, 2015, at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: > > Diego and I have discussed this according to the feedback received. We > have revised plan for this (see Diego's last reply). Here is a more > detailed re-cap: > > 1) keep MD_prof definition as it is today; also keep using the > frequency propagation as it is (assuming programs

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

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

...;Give me all annotations for a Value* >> >>/// Function local annotations >>Value* v = ... >>vector< const Annotation *> &ans = curFunction->lookupAnnotation( v, >>NULL, NULL); >> >>Or based on a specific type: >> >>/// Module wide annoations >>AnnotationType *type = ... >>Value< const Annotation *> &ans = module->lookupAnnotation( v, type, NULL ); >> >>This just random thought though. >> >> >>>>>As a historical curiosity, Function still needs to be annotatable due to >&...

hi Chris! thanks for your reply. First of all I did not know about the history with the Annotation stuff. Annotable for me was a way how one could realize this things. So as I see it right now - it is more that Annotable will completly vanish soon. This is interesting to me. Chris Lattner schrieb: > On Fri, 24 Feb 2006, Jakob Praher wrote: > >> When translating a complex c

> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com> wrote: > > On Thu, Feb 26, 2015 at 6:54 PM, Diego Novillo <dnovillo at google.com <mailto:dnovillo at google.com>> wrote: > > I've created a few bugzilla issues with details of some of the things I'll be looking into. I'm not yet done wordsmithing the overall design document.