llvm dev - Jun 2004 - [LLVMdev] X86 Frame info question

The X86 backend has this code:

   X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering
*IL)
     :  ....
         FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4),

That is, it uses "4" as local area offset. Based on prior discussion
this
should mean that the local area starts and address ESP+4. Is this really 
true? On X86 stack grows down, so I'd expect local area to start below ESP, 
e.g. at ESP - 4, and ESP + 4 would contains function arguments.

It look like prolog/epilog generator (PEI::calculateFrameObjectOffsets)
assumes local area offset is offset in the stack growth direction. For 
example, if there are 2 4-byte object, it will start with "Offset" of
4 and
then go to "Offset" of 8... the actuall offsets set to stack objects
will be
-Offset -- in this case -4 and -8. So, it really looks like local stack 
offset is specified in the direction of stack grows.

Is this so? Would you prefer if I change the docs to reflect this, or change 
the code so that LAO is specified independently of the stack growth 
direction? I think the latter aproach is more clean...

- Volodya

On Wed, 9 Jun 2004, Vladimir Prus wrote:
>
> The X86 backend has this code:
>
>    X86TargetMachine::X86TargetMachine(const Module &M,
IntrinsicLowering *IL)
>      :  ....
>          FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4),
>
> That is, it uses "4" as local area offset. Based on prior
discussion this
> should mean that the local area starts and address ESP+4. Is this really
> true? On X86 stack grows down, so I'd expect local area to start below
ESP,
> e.g. at ESP - 4, and ESP + 4 would contains function arguments.
Yup, the magic number 4 is due to the 'call' instruction pushing the
return address on the stack.

The TargetFrameInfo class is all about keeping the stack aligned at some
boundary (8 bytes in this case).  In particular, on entry to a function,
before the prolog, the stack pointer (on X86) is aligned to an 8 byte
boundary, but is actually 4 bytes from that alignment.  Put another way,
immediately before the call, the stack pointer was aligned to 8 bytes.
> It look like prolog/epilog generator (PEI::calculateFrameObjectOffsets)
> assumes local area offset is offset in the stack growth direction. For
> example, if there are 2 4-byte object, it will start with
"Offset" of 4 and
> then go to "Offset" of 8... the actuall offsets set to stack
objects will be
> -Offset -- in this case -4 and -8. So, it really looks like local stack
> offset is specified in the direction of stack grows.
That sounds right.  Immediately on entry to the function, ESP points to
the return address of the call.  ESP-4 is the start of the first object,
ESP-8 is the start of the second, etc.  Note that the TargetFrameInfo
keeps track of stuff *before* the prolog is emitted (as it doesn't know
what flavor of prolog will be output, that is up to the target and can
depend on properties of the function being compiled).
> Is this so? Would you prefer if I change the docs to reflect this, or
change
> the code so that LAO is specified independently of the stack growth
> direction? I think the latter aproach is more clean...
I think that making LAO -4 on the X86 would be fine, especially if it
makes the stack growth up/down case more consistent with each other.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Chris Lattner wrote:
> > It look like prolog/epilog generator
(PEI::calculateFrameObjectOffsets)
> > assumes local area offset is offset in the stack growth direction. For
> > example, if there are 2 4-byte object, it will start with
"Offset" of 4
> > and then go to "Offset" of 8... the actuall offsets set to
stack objects
> > will be -Offset -- in this case -4 and -8. So, it really looks like
local
> > stack offset is specified in the direction of stack grows.
>
> That sounds right.  Immediately on entry to the function, ESP points to
> the return address of the call.  ESP-4 is the start of the first object,
> ESP-8 is the start of the second, etc.  Note that the TargetFrameInfo
> keeps track of stuff *before* the prolog is emitted (as it doesn't know
> what flavor of prolog will be output, that is up to the target and can
> depend on properties of the function being compiled).
Yes, I understand this (more or less ;-) )
> > Is this so? Would you prefer if I change the docs to reflect this, or
> > change the code so that LAO is specified independently of the stack
> > growth direction? I think the latter aproach is more clean...
>
> I think that making LAO -4 on the X86 would be fine, especially if it
> makes the stack growth up/down case more consistent with each other.  :)
Ok, I'm hacking on this right now. Expect a patch in a couple of hours....

Thanks,
Volodya