llvm dev - Dec 2008 - [LLVMdev] Controlling the stack layout

Hi Nick,

Nick Johnson wrote:
>> I'd like to generate this layout:
>>
>> 12(%ebp)    - second function parameter
>> 8(%ebp)      - first function parameter
>> 4(%ebp)      - old %EIP (the function's "return address")
>> 0(%ebp)      - old %EBP (previous function's base pointer)
>> -4(%ebp)     - My language specific information
>> -8(%ebp)     - first local variable
>> -12(%ebp)   - second local variable
>>
>>     
>
> Take a look at the register allocators, each of which is implemented
> as a MachineFunctionPass.  These are responsible for assigning stack
> slots, and it shouldn't be too hard to modify them to reserve some
> stack slots.
>
>   
Thanks, but I don't want to modify the register allocators. I'd like to 
write an llvm-external machine pass.
> Also, I'd recommend that you consider the prevalence of this language
> specific information, and re-evaluate whether you want to modify the
> stack frame at all. 
Yes, I do :) There are some alternatives, but this looks like the most 
efficient. What I'm facing is engineering issues, since adding a new 
information in the stack frame is similar to adding the frame-pointer 
information.
>  Do you expect *every* function will need it, or
> *at most* every function will need it?  
Every function that I compile with llvm.
> Could this information also be
> encoded into a per-function local variable?  
No, because then you wouldn't know where the information is stored when 
walking the stack.
> Could your compiler
> generate code to maintain a separate stack for such information?
>
>   
Sure, but it's much more expensive than a simple push and pop.
> Also, out of curiosity: are you working on something like Java
> security contexts?  Or perhaps something like ProPolice canary values?
>
>   
I'm working on VMKit, which implements a JVM on top of LLVM. And an easy 
way to walk the stack is to have a methodID stored in each stack frame 
to locate which method the frame belongs to.

Nicolas

Hi, Nicolas
> Yes, I do :) There are some alternatives, but this looks like the most
> efficient. What I'm facing is engineering issues, since adding a new
> information in the stack frame is similar to adding the frame-pointer
> information.
I don't see any huge problems with writing such pass: just create
stack frame objects at fixed offsets inside your MF pass - and you'll
done. The only problem is that you need to do this early - before
prologue / epilogue inserter code runs, since afterwards stack frame
layout is almostly finalized (at "high level") and you'd deal with
much low-level and target-specific stuff.

I believe you can even use on of prologue-epilogue inserter hooks in
order to do this...

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Anton,

Anton Korobeynikov wrote:
> I don't see any huge problems with writing such pass: just create
> stack frame objects at fixed offsets inside your MF pass - and you'll
> done. The only problem is that you need to do this early - before
> prologue / epilogue inserter code runs, since afterwards stack frame
> layout is almostly finalized (at "high level") and you'd deal
with
> much low-level and target-specific stuff.
>
>   
OK.
> I believe you can even use on of prologue-epilogue inserter hooks in
> order to do this...
>   
Could you point me where those hooks are in the llvm code? I didn't find 
any.

Thanks!
Nicolas