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

[John Criswell]

On 7/8/11 4:49 PM, Andrew Ruef wrote:
> I investigated the MachineFunctionPass (that is runOnMachineFunction, 
> I believe).

A MachineFunctionPass is a class that you inherit from to write a 
transform that operates on MachineInstrs (i.e., native code instructions 
generated from the LLVM IR instructions).  The runOnMachineFunction() 
method is its entry point (i.e., the code generator calls 
runOnMachineFunction() for each MachineFunctionPass that it runs.

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

Is it possible that the function being compiled had a zero-sized stack 
frame?  If it has no spill slots or alloca instructions, and if the 
function parameters are not part of the stack frame, then it seems 
possible for the frame size to be zero to me.

You might also want to check and see if you're running your 
MachineFunctionPass at the right stage.  Perhaps some other 
MachineFunctionPass creates the FrameInfo objects and had not been run 
when your MachineFunctionPass was run?

Unfortunately, the code generator framework is mostly beyond what I 
know.  I only understand parts of it because I assisted a student in 
using it for a project.  I'm hoping those more knowledgeable can chime 
in.  If they don't, I can forward your question to the aforementioned 
student (he's not a regular on llvmdev, sadly).

-- John T.

>
> On Fri, Jul 8, 2011 at 5:21 PM, John Criswell <criswell at illinois.edu 
> <mailto: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
>>     <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  <mailto: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/e567e9bc/attachment.html>