llvm dev - Jul 2011 - [LLVMdev] Best location in code generation for insertion of instrumentation to measure stack depth?

Hi list,

I am trying to implement the technique outlined in the following paper:
http://www.cs.umd.edu/~mwh/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?

Thank you,

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

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_1MachineFunctionPass.html), 
MachineFunction 
(http://llvm.org/doxygen/classllvm_1_1MachineFunction.html), and 
MachineFrameInfo 
(http://llvm.org/doxygen/classllvm_1_1MachineFrameInfo.html).

-- 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>

I investigated the MachineFunctionPass (that is runOnMachineFunction, I
believe). In my experimentation it didn't seem that the MachineFrameInfo was
populated (it consistently said that the stack depth was 0, for example). I
might have been doing something wrong?

On Fri, Jul 8, 2011 at 5:21 PM, John Criswell <criswell at illinois.edu>
wrote:
>  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 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_1MachineFunctionPass.html),
> MachineFunction
(http://llvm.org/doxygen/classllvm_1_1MachineFunction.html),
> and MachineFrameInfo (
> http://llvm.org/doxygen/classllvm_1_1MachineFrameInfo.html).
>
> -- John T.
>
>
>  Thank you,
>
>  Andrew
>
>
> _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu        
http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110708/15a08142/attachment.html>