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 1/6]: Ping: Merge from Stack Branch - New data in function.h


On Wed, Apr 30, 2008 at 4:34 AM, Jan Hubicka <jh@suse.cz> wrote:
> > Jan,
>  >
>  > Can you please review for mainline?
>  >
>  > http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01019.html
>  Hi,
>  I can not really approve the generic bits of the patch, so RTL
>  maintainer will have to take a look.
>  The new placement in rtl_data seems fine to me. Do you have any idea how
>  often the code gets false positives (ie that stack_realign_needed is set
>  and stack_realign_really is not).

Joey, do we have such data? We did run SPEC CPU 2000/2006 on ia32
with -mpreferred-stack-boundary=2. Without stack realignment, there
are significant performance drop since double is aligned at 4 byte on
stack. With stack realignment, double is aligned at 8 byte on stack and
there is no performance change, except for 183.equake in SPEC CPU
2000 where there is 5% performance drop due to double is aligned
at 4 byte since it is the first argument of a function and we can't align
it at 8 byte without breaking psABI.

>  If I understand correctly, then we end up wasting pointer for argument
>  pointer (pseudo) register, but we don't actually emit the alignment prologue,
>  right?

I think so. Joey will confirm it.

>
>  The earlier attempt by Bernd to solve same problem
>  http://gcc.gnu.org/ml/gcc-patches/2002-05/msg02282.html
>  got around via reload's ellimination, but as I understand its major
>  problem was fixing esi and thus failing in combination with asm
>  statements and stringops...
>

Bernd, can you take a look at our patches? We changed to

#define PREFERRED_STACK_BOUNDARY_DEFAULT 128
#define STACK_REALIGN_DEFAULT (TARGET_64BIT ? 0 : 1)

in gcc stack branch. That is we realign stack for every function on Linux/ia32,
in both gcc itself and all testcases. The only "make check" failure is one new
testcase on stack branch:

FAIL: gcc.target/i386/stackalign/local-1.c -mno-stackrealign
scan-assembler-not sub[^\\n]*sp

That is we adjust stack unnecessarily.  I believe our solution works for  asm
statements and stringops... If you can show us a testcase, we will make it
to work.

Thanks.

H.J.


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