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