This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: [4.4/4.5 Regression] -fschedule-insns causes FAIL: gcc.target/i386/vararg-1.c execution test


> On Wed, Apr 7, 2010 at 2:27 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> On 04/07/2010 07:57 AM, H.J. Lu wrote:
> >>> Hi,
> >>>
> >>> "*sse_prologue_save_insn" generates movaps on 64bit aligned memory.
> >>> This patch replaces movaps with movups. ?OK for trunk and 4.3/4.4/4.5
> >>> branches?
> >>
> >> How is performance? ?Is it possible to detect alignment and use movaps
> >> in that case?
> >
> > Also the memory ought to be aligned as guaranteed by the ABI. ?We will then use movaps to read SSE argument via va_arg anyway.
> >
> 
> Here is the updated patch to align stack to 16byte for
> FP register save area in 64bit mode.OK for trunk/4.4/4.5?

I am bit worried about bumping up the alignemnt for not neccesary reason.  When
stack_alignment_needed is < 16, we know that function never used va_arg on XMM
type nor passed va_list to any function that might. (is this true also for
dynamic stack alignment?)

Bumping the stack alignments will in turn bump alignments of all functions that
use the function in question and in particular in integer only code this is
just wasteful.

I guess it is better to go the route of storing the 64bit halves only when this
happens.  I will prepare patch for that.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]