This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: [4.4/4.5 Regression] -fschedule-insns causes FAIL: gcc.target/i386/vararg-1.c execution test
> On Wed, Apr 07, 2010 at 04:22:33PM +0200, Jan Hubicka wrote:
> > > 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?)
>
> Note this should affect -O0 only (why do we allow scheduling for -O0
> anyway?), as for -O1+ the stdarg pass will find out that the function
> doesn't need any saving at all (and if it doesn't, the stack alignment
> would be 16).
Well, this will happen only in this trivial testcase, right? Not in case
function actually does va_arg on some 64bit argument or pass va_list to other
function that does so (but is already compiled and known to need 64bit
alignment only)
Honza
>
> Jakub