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

Andrew Ruef awruef at umd.edu
Fri Jul 8 15:06:43 PDT 2011

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,


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>

More information about the llvm-dev mailing list