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

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 (), MachineFunction (), and MachineFrameInfo (). – John T.

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?

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.

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