Re: fixes for gcc -falign-foo
On Wed, Jun 05, 2002 at 09:28:34PM -0700, Matthew Dillon wrote: > Hey Bruce or David... has GCC3 by any chance fixed the stack alignment > eyesore or is that still the default? If so could we by any chance fix > it in our version? It creates massive bloat when you have lots of tiny > functions and as far as I can tell there is no advantage at all except > for the occassional floating point intensive app. I really hate having > to specify -mpreferred-stack-boundary=2 in my builds. You can set GCC_OPTIONS="-mpreferred-stack-boundary=2" in your environment. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fixes for gcc -falign-foo
On Wed, 5 Jun 2002, Matthew Dillon wrote:
> Hey Bruce or David... has GCC3 by any chance fixed the stack alignment
> eyesore or is that still the default? If so could we by any chance fix
> it in our version? It creates massive bloat when you have lots of tiny
> functions and as far as I can tell there is no advantage at all except
> for the occassional floating point intensive app. I really hate having
> to specify -mpreferred-stack-boundary=2 in my builds.
Apparently not. It seems to have even added an extra stack alignment
instruction:
%%%
$ cat z.c
main()
{
foo();
bar(1, 2);
}
$ cc -O -S z.c
$ cat z.s
.file "z.c"
.text
.p2align 2,,3
.globl main
.type main,@function
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
andl$-16, %esp <---
callfoo
subl$8, %esp
pushl $2
pushl $1
callbar
leave
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 3.1 [FreeBSD] 20020509 (prerelease)"
%%%
This andl is precisely what is needed to get the stack to a known alignment
starting from an unknown one, but I think it should only be done if the
function has any local variables that need more than 4-byte alignment
(and/or if the cpu arch cares). But in the above it is just an extra
instruction if the caller has already aligned the stack.
The alignment and the extra alignment is even down when it is obviously
just wasted:
%%%
$ cat z.c
main()
{
}
$ cc -O3 -S z.c
$ cat z.s
.file "z.c"
.text
.p2align 2,,3
.globl main
.type main,@function
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp<-- old alignment
andl$-16, %esp <-- new alignment
leave <-- alignment not actually used
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 3.1 [FreeBSD] 20020509 (prerelease)"
%%%
I use the default for this except for compiling gcc itself.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fixes for gcc -falign-foo
Hey Bruce or David... has GCC3 by any chance fixed the stack alignment eyesore or is that still the default? If so could we by any chance fix it in our version? It creates massive bloat when you have lots of tiny functions and as far as I can tell there is no advantage at all except for the occassional floating point intensive app. I really hate having to specify -mpreferred-stack-boundary=2 in my builds. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fixes for gcc -falign-foo
I have been using the following fixes for gcc -falign-foo for almost
a month with no problem.
%%%
Index: toplev.c
===
RCS file: /home/ncvs/src/contrib/gcc/toplev.c,v
retrieving revision 1.13
diff -u -2 -r1.13 toplev.c
--- toplev.c9 May 2002 22:15:04 - 1.13
+++ toplev.c12 May 2002 14:22:43 -
@@ -4747,5 +4747,5 @@
}
- if (optimize < 2 || optimize_size)
+ if (optimize_size)
{
align_loops = 1;
Index: config/i386/i386.h
===
RCS file: /home/ncvs/src/contrib/gcc/config/i386/i386.h,v
retrieving revision 1.9
diff -u -2 -r1.9 i386.h
--- config/i386/i386.h 30 May 2002 06:04:14 - 1.9
+++ config/i386/i386.h 1 Jun 2002 20:49:25 -
@@ -762,5 +778,5 @@
/* Allocation boundary for the code of a function. */
-#define FUNCTION_BOUNDARY 16
+#define FUNCTION_BOUNDARY 8
/* Alignment of field after `int : 0' in a structure. */
%%%
The patch to toplev.c fixes a plain bug. gcc -O0 and -O1 didn't do
the easy optimization of alignment for space. They attempted to do
the easy optimization of alignment for time, which should be to 1-byte
alignment on i386's. However, the second bug forces the alignment to
2 bytes for functions only. The alignment should be to the
target-dependent default. This is in struct processor_target_table[]
in config/i386/i386.c on i386's. The defaults are very target-dependent
and much larger than 1 or 2 (e.g., 64 for align-jumps on athlons!).
The patch in i386.h permits -falign-foo=1 to work. It is not quite
right, because a boundary of 2 bytes is apparently required for C++.
This shouldn't be a problem, since the boundary shouldn't be 1 unless
the user really wants that boundary and sets it using -falign-functions=1.
However, the following cases give the too-small boundary of 1 even when
-falign-functions is not used:
- without the first patch: both -Oo and -O1
- with the first patch: -Os only.
The thread about the PR (http://gcc.gnu.org/ml/gcc/2002-05/msg00989.html)
doesn't seem to lead anywhere.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
