This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: stack manipulations in gcc-2.95.2
- To: Jeffrey A Law <law at cygnus dot com>
- Subject: Re: stack manipulations in gcc-2.95.2
- From: Jacob Navia <jacob at jacob dot remcomp dot fr>
- Date: Wed, 12 Jan 2000 10:18:15 +0100 (CET)
- Cc: gcc-bugs at gcc dot gnu dot org
In the attached zip file you will find all the code generated by gcc.
The command line for the compiler is:
gcc -g -O2 -DULONG_IS_32BIT -DULONG_NOT_DEFINED -S -c alglin2.c
The included file alglin2.s contains the code as generated by gcc -O2 -g
under windows NT mingw32. Using the stabs info you can see immediately
what assembler code corresponds to what source line of alglin2.c.
Note that there is NO FP code in that module, and that sequences of FOUR
or FIVE successive additions to the esp register are generated that will
always provoke a stall!!!!!!
Jacob Navia Logiciels/Informatique
41 rue Maurice Ravel Tel 01 48.23.51.44
93430 Villetaneuse Fax 01 48.23.95.39
France
On Wed, 12 Jan 2000, Jeffrey A Law wrote:
>
> In message <m1284xO-000Y2gC@jacob.remcomp.fr>you write:
> > Hi
> >
> > I have noticed that very often gcc generates code like:
> > addl $-8,%esp
> > pushl arg1
> > pushl arg2
> > call something
> > ...
> > addl 32,%esp
> > instead of the sequence used in most compilers:
> > pushl arg1
> > pushl arg2
> > call something
> > addl $8,%esp
> > that is 3 bytes shorter!
> Generally the compiler does. However, there are some circumstances where
> it can't (due to phase ordering issues).
>
>
> > To make things worst, there are often sequences like:
> > addl $32,%esp
> > addl $-4,%esp
> > addl $-8,%esp
> > instead of combining this into
> > addl $20,%esp
> > saving 6 bytes.
> I'd like to see sample code for this one. Again, due to phase ordering
> issues it is possible to get a pair of stack pointer adjustments back
> to back, but they're rare.
>
>
> > This is not a bad idea, but I am very skeptical if the code bloat that
> > this produces doesn't largely offset any possible gains for cache
> > alignment.
> Getting stack alignment right can mean a factor of 2 or more for FP intensive
> code on modern ia32 machines as measured by standard benchmarks like Spec.
>
> jeff
>
>
>
>
gccbug.zip