[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