[LLVMdev] Name of Function's original module during link-time optimization
sabre at nondot.org
Mon Sep 25 16:30:56 PDT 2006
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
> 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.
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.
More information about the llvm-dev