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

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>

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>

I was trying to figure out what phase in the invocation of the
MachineFunctionPasses the FrameInfo object was created from, but I couldn't
easily discern that from the documentation, or the code. If that information
exists, that would be very good to know.

I also wasn't able to find any documentation detailing creating a module
that is loadable by llc (via -load). Do you have any additional information
on that?

Thank you very much,

Andrew

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