This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to make gcc psABI conformant


On Wed, Oct 10, 2007 at 06:28:09AM -0700, H.J. Lu wrote:
> On Wed, Oct 10, 2007 at 09:10:06AM -0400, Daniel Jacobowitz wrote:
> > On Wed, Oct 10, 2007 at 06:05:01AM -0700, H.J. Lu wrote:
> > > > Isn't that STACK_BOUNDARY?  If not, since you seem to understand the
> > > > difference between these variables, could you improve the
> > > > documentation?
> > > 
> > > STACK_BOUNDARY is enforced by hardware. INCOMING_STACK_BOUNDARY is
> > > specified by psABI. INCOMING_STACK_BOUNDARY >= STACK_BOUNDARY.
> > 
> > Great, a third one...
> 
> For the backends which support INCOMING_STACK_BOUNDARY, we may
> undefine PREFERRED_STACK_BOUNDARY since we can align variables
> on stack properly.
> 
> > 
> > > That is we save the original stack pointer in the frame pointer and
> > > align the stack in prologue. It will touch frondend, middleend and
> > > backend. Will this scheme work for PowerPC?
> > 
> > Probably not.  I don't think we have the freedom to abuse the frame
> > pointer that way.  But the PowerPC case really ought to be simple,
> > modulo correct debug info.
> > 
> 
> Each backend needs to specify a hard register for the original stack
> pointer.  Using the frame pointer on x86 since it is less useful than
> others.  Will align stack cause problem for PowerPC?
> 

One more thing, when stack is aligned in prologue, the frame pointer
can no longer be used to access stack variables. That is another reason
to save the original stack pointer in it.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]