Bram Adams
2006-Sep-25 20:13 UTC
[LLVMdev] Name of Function's original module during link-time optimization
Hi, Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven:> What are you trying to accomplish? Why not use location records from > debug info?You mean the debugging intrinsics? Just discovered them :-), and I guess that's exactly what I need. 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. Kind regards, Bram Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060925/7031ba01/attachment.html>
Chris Lattner
2006-Sep-25 21:26 UTC
[LLVMdev] Name of Function's original module during link-time optimization
On Mon, 25 Sep 2006, Bram Adams wrote:> Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven: >> What are you trying to accomplish? Why not use location records from >> debug info? > > You mean the debugging intrinsics? Just discovered them :-), and I guess > that's exactly what I need. 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? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Bram Adams
2006-Sep-25 21:48 UTC
[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)
Possibly Parallel Threads
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization