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

[Chris Lattner]

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/