This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RPC] [patch] fix PR32893 - forcing alignment >= STACK_BOUNDARY (zlib segfault)
- From: Geert Bosch <bosch at adacore dot com>
- To: Dorit Nuzman <DORIT at il dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "Andrew Pinski" <pinskia at gmail dot com>, "Andrew_Pinski at playstation dot sony dot com" <Andrew_Pinski at playstation dot sony dot com>
- Date: Fri, 5 Oct 2007 22:07:45 -0400
- Subject: Re: [RPC] [patch] fix PR32893 - forcing alignment >= STACK_BOUNDARY (zlib segfault)
- References: <OFA2A6CDB1.8B07133B-ONC2257369.00270924-88257369.0066992D@il.ibm.com>
On Oct 3, 2007, at 14:40, Dorit Nuzman wrote:
This is probably because the STACK_BOUNDARY is not guaranteed to be
128bit
aligned on these systems. The vectorizer however is checking the
PREFERRED_STACK_BOUNDARY instead, and hopes for the best (i.e. we
knowingly
do something that may be wrong, but is ok most of the time). This,
by the
way, is also what would happen if we ask to align this array in the
source
code (e.g. using:
__attribute__ ((__aligned__(16)))
Can't we just explicitly align the stack frame to 128-bits during the
function
prologue, when we know that there are locals that require such
alignment?
I know it is a pain to do in general, because you typically use up an
extra register as the arguments and the locals do not have a constant
offset anymore. However, for functions that are worth vectorizing,
this cost shouldn't be prohibitive. Also, if 16-byte alignment is
explicitly requested, there is no other way to guarantee such alignment.
-Geert