Re: PATCH: PR target/40838: gcc shouldn't assume that the stack is aligned

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 19 Oct 2009, H.J. Lu wrote:

> On Mon, Oct 19, 2009 at 10:47 AM, Ian Lance Taylor <iant@google.com> wrote:
> > "H.J. Lu" <hjl.tools@gmail.com> writes:
> >
> >>> If somebody asked you "where does gcc set the required stack
> >>> alignment?" would you expect the answer to be "in the vectorizer
> >>> code?"

For sake of completeness: obviously not.  Any implementation where this 
answer would be true is broken (on one or the other level).

> >>> Is there any way we can fix incoming stack alignment so that it can 
> >>> be controlled by automatic stack variables? ÂI don't understand why 
> >>> this
> >>
> >> The incoming stack alignment can be controlled by automatic stack 
> >> variables. But it can't be controlled by pseudo registers.
> >>
> >>> is not done by the prologue and epilogue code.
> >>>
> >>
> >> Because the prologue and epilogue code is generated after RTL 
> >> expansion starts?
> >
> > That just restates my question without answering it.
> >
> 
> We don't "fix" the incoming stack alignment. We just need to know what 
> value it will be. Normally the incoming stack alignment is a constant 
> specified by psABI. I don't think we should change the way we do RTL 
> expansion just to work around a quirk in gcc implementation of i386 
> psABI.

Actually I think that we should change whatever we need to change for the 
change (ahem) to make sense.  You said:

> >> The incoming stack alignment can be controlled by automatic stack
> >> variables. But it can't be controlled by pseudo registers.

That doesn't make sense verbatim.  Why should the _incoming_ alignment (I 
understand this as the guarantee that the caller makes, "incoming" from 
the perspective of the called function) be influenced by anything the 
given function does or doesn't do to the stack.  I guess there's some 
confusion with the terms, so please clarify.

You also said:

[Ian]
> > > I don't understand why this
> > > is not done by the prologue and epilogue code.

[H.J.]
> > Because the prologue and epilogue code is generated after RTL
> > expansion starts?

Somewhere we're going downhill with understanding.  I assume that stack 
alignment work (if necessary) is done in the prologue.  I further assume 
that required stack alignment depends on emitted calls and stack slots in 
the body.

So if (as you say right above) prologue is emitted after the expansion of 
all real instructions (which then includes arbitrary temporaries, but not 
spill slots), it should be very well able to emit whatever insns necessary 
to guarantee the alignment required depending on the guaranteed incoming 
alignment.

(Ignore for a moment that currently the function start is not emitted 
after everything else, but before.  For discussion purpose assume that the 
function start is emitted after everything else.)


Ciao,
Michael.