This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/6]: Ping: Merge from Stack Branch - New data in function.h
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Jan Hubicka" <jh at suse dot cz>, bernd dot schmidt at analog dot com
- Cc: "Ye, Joey" <joey dot ye at intel dot com>, "GCC Patches" <gcc-patches at gcc dot gnu dot org>, "Jan Hubicka" <hubicka at ucw dot cz>, "Guo, Xuepeng" <xuepeng dot guo at intel dot com>
- Date: Wed, 30 Apr 2008 06:49:25 -0700
- Subject: Re: [PATCH 1/6]: Ping: Merge from Stack Branch - New data in function.h
- References: <BB577BF501703042AD7E08EADD8E514FF5DC8C@pdsmsx415.ccr.corp.intel.com> <20080430113432.GW932@kam.mff.cuni.cz>
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.