[LLVMdev] Name of Function's original module during link-time optimization

Bram Adams bram.adams at ugent.be
Mon Sep 25 14:48:47 PDT 2006


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)



More information about the llvm-dev mailing list