search for: annotater

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

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

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

On Fri, 24 Feb 2006, Jakob Praher wrote: > 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. ok. > 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

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):

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.

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

> thanks for your reply. Sorry for the delay, I've been buried in email lately. >>> When translating a complex c application to llvm bytecodes, some >>> semantics are lost: >>> >> LLVM 1.6 and the "new front-end" already handle this right. Here's the >> bugzilla bug corresponding to it: >>

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

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

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 Jul 25, 2008, at 16:57, John Criswell wrote: > Devang Patel wrote: > >> On Jul 25, 2008, at 12:58 PM, Marc de Kruijf wrote: >> >> I'd like to write a pass that does both: implements a code >> transformation and saves information that can be accessed by >> subsequent passes. >> >> Ideally, we want to use two separate pass. However, it is

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

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

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