[LLVMdev] Best location in code generation for insertion of instrumentation to measure stack depth?

John Criswell criswell at illinois.edu
Fri Jul 8 14:21:53 PDT 2011

On 7/8/11 4:09 PM, Andrew Ruef wrote:
> Hi list,
> I am trying to implement the technique outlined in the following 
> paper: http://www.cs.umd.edu/~mwh/papers/martin10ownership.html 
> <http://www.cs.umd.edu/%7Emwh/papers/martin10ownership.html> in LLVM. 
> My approach so far involves the use of an IR level transform (via 
> runOnFunction) to identify memory loads and stores. One thing I need 
> to do (I am pretty sure I need to do it at least) is automatically 
> mark each stack frame as "owned" by the current thread.
> I'm not sure where the best place in the LLVM architecture to do this 
> is. As I currently understand it, the concept of a stack frame appears 
> pretty late in target code generation. I've hacked in a hook for this 
> in X86FrameLowering.cpp in the emitPrologue and emitEpilogue methods.
> Is there a cleaner way I can do this? Is there a way I can subclass 
> the X86 code generator to "hook" those two methods and insert my 
> instrumentation? Is there something I'm missing with 
> runOnMachineFunction?

I'm stepping beyond what I know a little bit, but have you looked at 
writing a MachineFunctionPass?  A student here at Illinois wrote a 
MachineFunctionPass to insert additional epilogue code into functions.  
Assuming that it's possible, putting your functionality into a 
MachineFunctionPass should be cleaner than modifying the code generator 
directly (MachineFunctionPass'es may even be load-able into llc).

Check out the doxygen docs for MachineFunctionPass 
(http://llvm.org/doxygen/classllvm_1_1MachineFunction.html), and 

-- John T.

> Thank you,
> Andrew
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110708/b72255f3/attachment.html>

More information about the llvm-dev mailing list