[RFA]: Merge stack alignment branch

[Ye, Joey]

Jan,

As to your comments about expand_one_var:
> It seems a bit overzelaous to track the alignment everywhere.  The
> variables ends up either on stack or in pseudo.  In both cases the
> stack_alignment_estimated shold be bumped already? 
As I said in code comments, we don't know if a static variable would be
spilled to stack or not when expanding it. Current strategy is to
estimate it very conservatively. It is not the most optimized way and
there is room for tuning. I'd like to leave it for later patches.

Good news is that even if stack alignment estimation is too conservative
in expansion, fixing up code after reload can reduce the penalty to as
less as zero or one additional instruction depends on DARP usage.

Attached case shows and static variable end up spilled into stack later.

As to your comments:
> @@ -2968,6 +3010,20 @@ assign_parms (tree fndecl)

> That TYPE_ALIGN bump seems wrong.  If you want to pass that type
> aligned, FUNCTION_ARG_BOUNDARY should return proper value?
This is optimization of estimation. For following funtion
typedef int __attribute__((aligned (16)) type_a;
void foo(type_a arg) {...}

Arg can be copied into vreg and spilled to stack. The stack alignment
will be increased to align_of(int), but not align_of(type_a). So we
estimate stack alignment from TYPE_ALIGN instead.

> When incomming argument or return value is aligned, why it affects the
> function's stack frame alignment at all? Those live in the caller
> function stack frame that is already aligned.
Again, it is an estimation. Incomming argument can be copied into a
virtual reg and finally spilled into stack.

> Do we take into account that the alignment of stack pointer is known
and
> we don't need to re-align?
Yes. If incoming_stack_boundary >= stack_alignment_estimated, then no
re-align is needed. Incoming_stack_boundary depends on ABI and
PREFERRED_STACK_BOUDNARY.

Thanks - Joey

-----Original Message-----
From: Jan Hubicka [mailto:hubicka@ucw.cz] 
Sent: Friday, April 11, 2008 6:04 PM
To: Ye, Joey
Cc: GCC Patches; Lu, Hongjiu; Guo, Xuepeng; ubizjak@gmail.com
Subject: Re: [RFA]: Merge stack alignment branch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slot.c
Type: application/octet-stream
Size: 279 bytes
Desc: slot.c
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080414/a13255e6/attachment.obj>