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

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Mon, Oct 22, 2007 at 12:39:39PM -0500, Mark Mitchell wrote:
>> 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.
> 
> FYI, as I learned recently, powerpc-linux is one target where
> STACK_BOUNDARY is smaller than PREFERRED_STACK_BOUNDARY - but
> in fact GCC and the ABI always arrange for the larger alignment.
> So a new macro may be called for to continue taking advantage of
> AltiVec in the vectorizer.

I see.  It's possible that I don't understand what these macros do
exactly, but, given my reading of the documentation, I agree.  I think
we should have a ABI_STACK_BOUNDARY that says what the minimum stack
boundary is guaranteed to be by the ABI.  The default would be
STACK_BOUNDARY.  The default for PREFERRED_STACK_BOUNDARY would then be
ABI_STACK_BOUNDARY, not STACK_BOUNDARY.

The idea is that STACK_BOUNDARY says what the hardware requires.
ABI_STACK_BOUNDARY says what the ABI requires.  PREFERRED_STACK_BOUNDARY
says what alignment we preserve within a given function.  Manually
setting the preferred stack boundary (-mpreferred-stack-boundary) below
ABI_STACK_BOUNDARY should be an error, since it's not ABI compatible.

The vectorizer could use ABI_STACK_BOUNDARY as the maximum allowed
alignment for things, since we know that we'll have at least that
alignment within any function.

I still think that allowing making arbitrary alignment for local
variables work is a good idea.  Then, users and optimization passes can
just align things as they like.  Paying a few extra instructions in the
prologue to get things set up is a huge win if it allows vectorization
of some loop.

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