search for: annotatable

I recently updated my Rannotate application. The interface has been completely redone and there are lots of new features. The basic idea is to create searchable and user annotatable documentation for the Ruby on Rails API (think php.net). Check it out at - http://rails.outertrack.com * What is Rannotate? Rannotate is a Rails application and RDoc YAML generator that work together to provide user submitted notes for rdoc generated documentation. It is modeled after the suc...

...ed 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...

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, As far as I know, Instruction class does not inherit "Annotable" Class. Only Function inherits annotable according to the documentation of annotable class. What you are asking would require adding annotations at instruction level, which does not seem to be possible. You can maintain external maps between instructions and your annotations, --Kapil On Thu, Mar 5, 2009 at 7:17 PM,

On Tue, 26 Sep 2006, Bram Adams wrote: > > A limitation here is that only Functions' debug data can be kept, as > other Values (i.e. Instructions) are not Annotable. Is this an explicit > design decision? Yes, we intentionally do not want things to be annotatable. In fact, Function being annotatable is a wart due to the way the code generator currently works. In general, we prefer to keep data in on-the-side maps instead of attached to the IR. The mailing list has archives of extensive discussion about this sort of thing. -Chris -- http://nondot.o...

Hi, Chris Lattner wrote: > I'd suggest writing a little pass that strips out debug intrinsics. > OK, I did this and it works (the strange seg fault also disappears after all declared debug variables are gone)! In a first phase, all intrinsic instructions are discarded after extracting their data into annotations attached to the relevant Function. Then, a second phase wipes out the

...ly possible. > > Why not make things like Instructions Annotable too? > For instance pointer creating Instructions, like alloca, malloc, .. > would be nice if they could be Annotable and so one could add symbolic > information to the type beeing used. At one point in time, Value was annotatable. The problem with this was two fold: 1. This bloat every value in the system, by adding an extra pointer. 2. These annotations would get stale and not be updated correctly. The problem is basically that adding annotations really amounts to extending the LLVM IR, and making it look like somethi...

Hello together, how can i insert annotations in IR ? I want actually write something like: CallInst *call = CallInst::Create( ??? , aBasicBlock); in my pass. Regards Raad -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090305/cd1db761/attachment.html>

hi all, out of a matter of fact I am still using llvm version 1.5. I don't know how 1.6 works in this matter. When translating a complex c application to llvm bytecodes, some semantics are lost: Take for isntance the interesting attribute to put a variable in the thread local data section (.tdata), this would be interesting to have in llvm. like in GCC you write: int x

On 27.04.2016 11:00, Heiko Schlittermann wrote: > Hi, > >> ? 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 dovecot: imap(heiko):

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

...er Linux. > >> >> I would generally be interested and could contribute to extending LLVM >> by allowing more Annotatinons than currently possible. Okay so I am on quite the opposite attitude than the LLVM team towards that issue :-) > > At one point in time, Value was annotatable. The problem with this was > two fold: > > 1. This bloat every value in the system, by adding an extra pointer. > 2. These annotations would get stale and not be updated correctly. > > The problem is basically that adding annotations really amounts to > extending the LLVM IR,...

...I would generally be interested and could contribute to extending LLVM >>> by allowing more Annotatinons than currently possible. > Okay so I am on quite the opposite attitude than the LLVM team towards > that issue :-) I don't follow. >> At one point in time, Value was annotatable. The problem with this was >> two fold: >> >> 1. This bloat every value in the system, by adding an extra pointer. >> 2. These annotations would get stale and not be updated correctly. >> >> The problem is basically that adding annotations really amounts to >...

As noted on my blog and at http://www.opensolaris.org/os/community/dtrace/shells/ I''ve made available a DTrace provider for the Bourne shell. Before anyone starts yelling at me for not starting with another shell, read the blog I made explaining why we started with shell (link on the community page referenced above). For /bin/sh, I''ve put up something akin to a chapter in

...uld 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...

...t the end) where it doesn't have any impact on LLVM (JIT/storage/etc). The only question is: how do multiple tools avoid collision in this approach. Some kind of registry or partitioning of the data could likely solve that. > > > As a historical curiosity, Function still needs to be annotatable due to > > the LLVM code generator relying on it. This will be fixed in LLVM 1.8 > > and Function will not be annotable anymore. > > > > If you *really* just want per-pass local data, you should just use an > > std::map from the Value* to your data. > > Why no...

...ture it as an ImmutablePass (with an explicit pass to free the contained information) because it would be invalidated by other passes at random. This is essentially the same approach used to manage the MachineFunction representation. Speaking of which, I also have also attempted to eliminate Annotatable by storing the MachineFunction in a FunctionPass analysis used only to maintain the MachineFunction representation. That experiment failed for essentially the same reason. (It would've succeeded if I'd thought to use an ImmutablePass at the time.) Unsatisfactory. — Gordon

...( 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 will be fixed in LLVM 1.8 >>>and Function will not be annotable anymore. >>> >>>If you *really* just want per-pass local data, you should just use an >>>std::map from the Value* to your data. >&gt...

Folks, Is api.rubyonrails.com the best source for RoR API info? Do any other formats exist, that are easier to navigate/search? Thanks, Marcus Marcus Blankenship Technology Services - Software Group JELD-WEN, inc. Information Systems 541-882-3451 x 2558 marcusb@jeld-wen.com RELIABILITY for real life* This correspondence is for the named person''s use only. It may contain

...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 will be fixed in LLVM 1.8 > >>>and Function will not be annotable anymore. > >>> > >>>If you *really* just want per-pass local data, you should just use an > >>>std::map from the Val...