Re: ping [RFC] [patch] fix PR32893 - forcing alignment >= STACK_BOUNDARY

[Mark Mitchell <mark at codesourcery dot com>]

H.J. Lu wrote:
> On Sun, Oct 21, 2007 at 09:05:38PM -0800, Dorit Nuzman wrote:
>> So I'm not sure how to proceed with PR32893 (see details and proposed patch
>> below).
>>
>> I didn't yet get a response from Pinsky on whether his fix for PR16660
>> would also fix this PR,
> We are working on a proposal to properly fix the stack alignment issue.
> We will start a project for gcc 4.4.

Dorit --

For GCC 4.3, I don't think you have a choice: you need to change the
vectorized to use plain STACK_BOUNDARY, because that's all the compiler
can actually support.  I understand the performance cost, but
correctness has to trump performance.  ABIs designed to support vector
instructions will probably ensure that STACK_BOUNDARY is large enough
that this is not an issue.

What we probably want in the long term is for the compiler (including
the vectorized) to be able to generate variables with arbitrary
alignment in all functions.  I would expect the implementation of that
would be relatively simple; in the function prologue, you would notice
that this is a function containing a variable of alignment N (greater
than STACK_BOUNDARY) and generate fixup code to ensure that the stack
was so aligned.  So, the cost would only be borne by functions with
variables requiring large alignment, and, even there, it just be a few
instructions in the prologue.  Perhaps this is as simple as setting
PREFERRED_STACK_BOUNDARY to max(user-specified-preferred-stack-boundary,
biggest-alignment-used-in-this-function) at the start of generating RTL
for a function.

Certainly, I also think that the compiler should generate an error if it
cannot honor an alignment directive.  For example, in PR 16660, we
should generate an error on the declaration of "tmp" if we cannot
actually align it on a 16-byte boundary.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713