llvm dev - Sep 2006 - [LLVMdev] Name of Function's original module during link-time optimization

Hi,

Op 25-sep-06, om 23:26 heeft Chris Lattner het volgende geschreven:
> On Mon, 25 Sep 2006, Bram Adams wrote:
>> Haven't tried them extensively yet, so I'm
>> wondering whether the remark in your mail of 09/04/2006 to Nikhil  
>> Patil about
>> "-g currently disables many optimizations" still holds.
>
> Yes, that is true.  What are you trying to do?
Basically, I'm working on an aspect weaver (next version of http:// 
users.ugent.be/~badams/aspicere/) where the weaving functionality is  
performed at link-time by some LLVM passes I'm writing. As advice  
frequently needs join point-specific context information like the  
name of the woven advice, of the current method, of the current  
compilation unit, ... I provide this info by storing it in an LLVM  
struct passed at run-time to the advice (which has been transformed  
into a Function earlier). That's why I need to know the name of the  
module to which a Function originally belonged.

About the debugging intrinsics: I've did some small tests using
"-g",
but I got a segmentation fault in one of my passes. The error wasn't  
there before (i.e. before using -g), but I need to delve a bit deeper  
first before I can give meaningful details. However, the debugging  
code in the LLVM bytecode seems huge, so I'm wondering whether some  
more "limited" forms of the "-g"-flag exist? Finally, as
I'm heavily
relying on LLVM's optimization passes to clean up the woven code  
(remove unused context, ...), the "-g currently disables many  
optimizations" is an important concern to me.

Maybe an initial InstVisitor pass attaching the debug info as  
Annotations to Functions, ... while discarding the debugging  
instructions could solve these problems, as both the debugging info  
would be available in the IR to subsequent passes and the existing  
optimization passes (ignoring the Annotations) could remain  
unchanged. Could this approach be feasible? If so, I could put  
something together tomorrow.

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

On Mon, 25 Sep 2006, Bram Adams wrote:
>> On Mon, 25 Sep 2006, Bram Adams wrote:
>>> Haven't tried them extensively yet, so I'm
>>> wondering whether the remark in your mail of 09/04/2006 to Nikhil
>>> Patil about
>>> "-g currently disables many optimizations" still holds.
>>
>> Yes, that is true.  What are you trying to do?
>
> Basically, I'm working on an aspect weaver (next version of http://
> users.ugent.be/~badams/aspicere/) where the weaving functionality is
> performed at link-time by some LLVM passes I'm writing. As advice
ok.
> frequently needs join point-specific context information like the
> name of the woven advice, of the current method, of the current
> compilation unit, ... I provide this info by storing it in an LLVM
> struct passed at run-time to the advice (which has been transformed
> into a Function earlier). That's why I need to know the name of the
> module to which a Function originally belonged.
ok.
> About the debugging intrinsics: I've did some small tests using
"-g",
> but I got a segmentation fault in one of my passes. The error wasn't
> there before (i.e. before using -g), but I need to delve a bit deeper
> first before I can give meaningful details. However, the debugging
> code in the LLVM bytecode seems huge, so I'm wondering whether some
> more "limited" forms of the "-g"-flag exist? Finally,
as I'm heavily
> relying on LLVM's optimization passes to clean up the woven code
> (remove unused context, ...), the "-g currently disables many
> optimizations" is an important concern to me.
Right.  It seems like you would be well served by building with debug info 
(which captures a variety of source level information), run your 
instrumentation pass, run a pass to strip out the debug info, then run 
optimizers as needed.

Note that file-level information is not all you're losing.  When/if the 
inliner (or any other interprocedural pass) runs, will will mess up the 
usual notion of a function, so you can't rely on function names either.
> Maybe an initial InstVisitor pass attaching the debug info as
> Annotations to Functions, ... while discarding the debugging
> instructions could solve these problems, as both the debugging info
> would be available in the IR to subsequent passes and the existing
> optimization passes (ignoring the Annotations) could remain
> unchanged. Could this approach be feasible? If so, I could put
> something together tomorrow.
I'd suggest writing a little pass that strips out debug intrinsics.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

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 
intrinsic instruction Functions themselves as well as all debug 
variables in the declaration section. This 2-phase approach is necessary 
as I implemented the pass as an InstVisitor.

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?

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University

PS: Could this pass be interesting to others? If so, I could send the 
code to the list or to Bugzilla.