[LLVMdev] X86 Frame info question

Chris Lattner sabre at nondot.org
Wed Jun 9 02:47:01 PDT 2004


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/





More information about the llvm-dev mailing list