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

Ian Lance Taylor iant@google.com
Mon Oct 19 21:15:00 GMT 2009


"H.J. Lu" <hjl.tools@gmail.com> writes:

> 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?"
>>>
>>> Yes, vectorizer may put requirement on stack alignment. But it is up
>>> to backend to decide and it isn't the only place gcc may require
>>> certain stack alignment.
>>
>> It's the only place your patch changes.
>
> I also changed ix86_minimum_alignment to handle
> automatic stack variables.

OK, the only middle-end place.


>>>> 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.

I'm not sure I understand what you mean here.  The incoming stack
alignment is still a constant, isn't it?  Does using a vector somehow
change the incoming stack alignment?

Ian



More information about the Gcc-patches mailing list