Re: stack alignment issues
Bruce, On Tue, Feb 05, 2002 at 05:01:29PM +1100, Bruce Evans wrote: My patch is not suitable for committing verbatim. It has 2 or 3 XXX's. Do you make these patches available anywhere, so that other people can look over them and maybe help you on the XXX'd sections? N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg31430/pgp0.pgp Description: PGP signature
Re: stack alignment issues
On Tue, 5 Feb 2002, Nik Clayton wrote: On Tue, Feb 05, 2002 at 05:01:29PM +1100, Bruce Evans wrote: My patch is not suitable for committing verbatim. It has 2 or 3 XXX's. Do you make these patches available anywhere, so that other people can look over them and maybe help you on the XXX'd sections? Erm, I'm replying to mail that gave a URL for my old mail with the patch. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Tue, 5 Feb 2002, Bruce Evans wrote: On Mon, 4 Feb 2002, Mike Silbersack wrote: On Tue, 5 Feb 2002, Bruce Evans wrote: I haven't done anything to clean up the patch. I hope the problem will go away in future versions of gcc (align the stack at runtime in the few routines that actually need it). Well, if Linux aligns the initial stack, the chance that gcc will have auto-alignment added sounds to be about zero. You might as well go ahead with your patch when you get a chance. There is a nonzero probability that the pessimization of aligning in almost every routine will be fixed someday. Actually, the pessimization is worse -- the alignment is done before every call. Even so, I'd wager that you can align the initial stack a few months ahead of when gcc's alignment is improved. foo: pushl %ebp movl %esp,%ebp subl $8,%esp# - extra instruction for alignment (for foo) addl $-12,%esp # - extra instruction for alignment (for f1) What disgusting code. I find it amazing that they didn't even stick in some peephole optimizer to at least limit it to one operation. My patch is not suitable for committing verbatim. It has 2 or 3 XXX's. Bruce True, but I'm sure you're capable of fixing it up if you so desire. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Tue, 5 Feb 2002, Mike Silbersack wrote: On Tue, 5 Feb 2002, Bruce Evans wrote: foo: pushl %ebp movl %esp,%ebp subl $8,%esp# - extra instruction for alignment (for foo) addl $-12,%esp # - extra instruction for alignment (for f1) What disgusting code. I find it amazing that they didn't even stick in some peephole optimizer to at least limit it to one operation. It's clearly the result of work in progress :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
* Bruce Evans [EMAIL PROTECTED] [020205 12:09] wrote: On Tue, 5 Feb 2002, Mike Silbersack wrote: On Tue, 5 Feb 2002, Bruce Evans wrote: foo: pushl %ebp movl %esp,%ebp subl $8,%esp# - extra instruction for alignment (for foo) addl $-12,%esp # - extra instruction for alignment (for f1) What disgusting code. I find it amazing that they didn't even stick in some peephole optimizer to at least limit it to one operation. It's clearly the result of work in progress :-). I see really cruddy stuff like this every time i do a gcc -S, don't they watch for and try to fix this sort of thing? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
: : What disgusting code. I find it amazing that they didn't even stick in : some peephole optimizer to at least limit it to one operation. : : It's clearly the result of work in progress :-). : :I see really cruddy stuff like this every time i do a gcc -S, don't :they watch for and try to fix this sort of thing? : :-- :-Alfred Perlstein [[EMAIL PROTECTED]] I've been forced to add -mpreferred-stack-boundary=2 to critical code in certain projects to get rid of the crap GCC adds to the assembly. I don't mind if GCC aligns the stack for routines that actually need it, but what it does now - assume that the stack is already aligned and then realign in every single fragging procedure call is utterly and completely stupid. Someone should shoot the idiot that put that into the tree. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
* Matthew Dillon [EMAIL PROTECTED] [020205 12:28] wrote: I've been forced to add -mpreferred-stack-boundary=2 to critical code in certain projects to get rid of the crap GCC adds to the assembly. I don't mind if GCC aligns the stack for routines that actually need it, but what it does now - assume that the stack is already aligned and then realign in every single fragging procedure call is utterly and completely stupid. Someone should shoot the idiot that put that into the tree. Now Matt... tell us how you really feel. :) Better yet, flame the gcc developers and tell them to fix this ungodly breakage. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Tue, 5 Feb 2002, Alfred Perlstein wrote: * Bruce Evans [EMAIL PROTECTED] [020205 12:09] wrote: On Tue, 5 Feb 2002, Mike Silbersack wrote: On Tue, 5 Feb 2002, Bruce Evans wrote: foo: pushl %ebp movl %esp,%ebp subl $8,%esp# - extra instruction for alignment (for foo) addl $-12,%esp # - extra instruction for alignment (for f1) What disgusting code. I find it amazing that they didn't even stick in some peephole optimizer to at least limit it to one operation. It's clearly the result of work in progress :-). I see really cruddy stuff like this every time i do a gcc -S, don't they watch for and try to fix this sort of thing? -- -Alfred Perlstein [[EMAIL PROTECTED]] Did you see that press release about how Microsoft is taking a month off from coding new features and dedicating everyone to fixing bugs? I can see an analogous headline: FreeBSD developers get sick of gcc's code generation, devote March to compiler rewrite and in related news: Brett Glass finds out that FreeBSD developers are working on gcc and suffers a nervous breakdown. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Mon, 04 Feb 2002 15:36:11 -0800 Terry Lambert [EMAIL PROTECTED] wrote: Alfred Perlstein wrote: Well, if Linux aligns the initial stack, the chance that gcc will have auto-alignment added sounds to be about zero. You might as well go ahead with your patch when you get a chance. I agree, either way we should try to optimized the current situation, especially if it seems to give a 2x perf boost! How about aligning the initial stack? i think this is a good idea (besides trying to optimize gcc). and it shouldn't be too hard to accomplish this (i don't know the code for rtld, but it really shouldn't be too hard to do this) unfortunately i don't have time ATM otherwise i'd look into this cheerz corecode -- /\ http://corecode.ath.cx/ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News msg31490/pgp0.pgp Description: PGP signature
Re: stack alignment issues
Greg Shenaut wrote: In message [EMAIL PROTECTED], Dan Nelson cleopede: In the last episode (Feb 03), Alfred Perlstein said: * Michal Mertl [EMAIL PROTECTED] [020203 08:17] wrote: Not really sure what to make of this, anyone else know how we ought to fix this? This has actually been an issue for ages, most commonly seen with doubles. take a look at the thread at Has any real world program ever been significantly affected by this problem? I don't know any such program but I suppose they exist. The problem is probably generaly unnoticed by the people running the program. FWIW OpenBSD 2.6 has the same problem but Linux (kernel 2.0 and 2.4) is unaffected. Did you look at the patch by Bruce at http://groups.yahoo.com/group/freebsd-current/message/39605 ? Bruce, is it still fresh in your memory? Can you comment on the patch - can it be commited in some form? -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Mon, 4 Feb 2002, Michal Mertl wrote: Did you look at the patch by Bruce at http://groups.yahoo.com/group/freebsd-current/message/39605 ? Bruce, is it still fresh in your memory? Can you comment on the patch - can it be commited in some form? I haven't done anything to clean up the patch. I hope the problem will go away in future versions of gcc (align the stack at runtime in the few routines that actually need it). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Tue, 5 Feb 2002, Bruce Evans wrote: On Mon, 4 Feb 2002, Michal Mertl wrote: Did you look at the patch by Bruce at http://groups.yahoo.com/group/freebsd-current/message/39605 ? Bruce, is it still fresh in your memory? Can you comment on the patch - can it be commited in some form? I haven't done anything to clean up the patch. I hope the problem will go away in future versions of gcc (align the stack at runtime in the few routines that actually need it). Bruce Well, if Linux aligns the initial stack, the chance that gcc will have auto-alignment added sounds to be about zero. You might as well go ahead with your patch when you get a chance. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
* Mike Silbersack [EMAIL PROTECTED] [020204 10:04] wrote: On Tue, 5 Feb 2002, Bruce Evans wrote: On Mon, 4 Feb 2002, Michal Mertl wrote: Did you look at the patch by Bruce at http://groups.yahoo.com/group/freebsd-current/message/39605 ? Bruce, is it still fresh in your memory? Can you comment on the patch - can it be commited in some form? I haven't done anything to clean up the patch. I hope the problem will go away in future versions of gcc (align the stack at runtime in the few routines that actually need it). Bruce Well, if Linux aligns the initial stack, the chance that gcc will have auto-alignment added sounds to be about zero. You might as well go ahead with your patch when you get a chance. I agree, either way we should try to optimized the current situation, especially if it seems to give a 2x perf boost! -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
On Mon, 4 Feb 2002, Mike Silbersack wrote:
On Tue, 5 Feb 2002, Bruce Evans wrote:
I haven't done anything to clean up the patch. I hope the problem
will go away in future versions of gcc (align the stack at runtime in
the few routines that actually need it).
Well, if Linux aligns the initial stack, the chance that gcc will have
auto-alignment added sounds to be about zero. You might as well go ahead
with your patch when you get a chance.
There is a nonzero probability that the pessimization of aligning in almost
every routine will be fixed someday. Actually, the pessimization is worse
-- the alignment is done before every call.
Example:
%%%
foo.c:
foo()
{
f1(1);
f2(2);
f3(3.0);
}
%%%
gcc -O -S [-mpreferred-stack boundary] currently generates the following
code for this:
%%%
.file z.c
.version01.01
gcc2_compiled.:
.section.rodata
.p2align 3
.LC0:
.long 0x0,0x4008
.text
.p2align 2,0x90
.globl foo
.typefoo,@function
foo:
pushl %ebp
movl %esp,%ebp
subl $8,%esp# - extra instruction for alignment (for foo)
addl $-12,%esp # - extra instruction for alignment (for f1)
pushl $1
call f1
addl $-12,%esp # - extra instruction for alignment (for f2)
pushl $2
call f2
addl $32,%esp # - extra instruction for alignment (for f3)
addl $-8,%esp # - extra instruction for alignment (another)
pushl .LC0+4
pushl .LC0
call f3
leave
ret
.Lfe1:
.sizefoo,.Lfe1-foo
.ident GCC: (c) 2.95.3 20010315 (release)
%%%
It should generate something like:
.file z.c
.version01.01
gcc2_compiled.:
.section.rodata
.p2align 3
.LC0:
.long 0x0,0x4008
.text
.p2align 2,0x90
.globl foo
.typefoo,@function
foo:
pushl %ebp
movl %esp,%ebp
andl $~0x7,%esp # - extra instruction for alignment (for foo)
# Only needed since foo() uses FPU.
# 8-byte alignment enough for doubles?
# Adjust in prologue so that there are
# hopefully no alloca()-like issues, except
# we need a frame pointer to restore %esp.
pushl $1
call f1
pushl $2
call f2
pushl .LC0+4
pushl .LC0
call f3
leave
ret
.Lfe1:
.sizefoo,.Lfe1-foo
.ident GCC: (c) 2.95.3 20010315 (release)
%%%
My patch is not suitable for committing verbatim. It has 2 or 3 XXX's.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues (was: unbelievable benchmark output)
On Sun, 3 Feb 2002 08:59:41 -0800 Alfred Perlstein [EMAIL PROTECTED] wrote: Hi, It sure looks like an alignment issue. If you print the address of 'i' and 'j' in the attached program you can see for the fast case they are aligned to 8 byte boundries, but when it's slow they are at an address that is a multiple of 4 but not 8. Agreed, my bet is on data alignment. Not really sure what to make of this, anyone else know how we ought to fix this? Well, you could always malloc() some memory and make sure your data is in an address that is multiple of 8. You'll waste some mem but will gain performance. I actually haven't tried it on FreeBSD but it's a trick I used to do on the Amiga some years ago. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues (was: unbelievable benchmark output)
In the last episode (Feb 03), Alfred Perlstein said: * Michal Mertl [EMAIL PROTECTED] [020203 08:17] wrote: Several runs of the program take about the same time but the time changes wildly when the executable is called differently. The only thing which I can think of that can be causing this is some memory alignment issue. It sure looks like an alignment issue. If you print the address of 'i' and 'j' in the attached program you can see for the fast case they are aligned to 8 byte boundries, but when it's slow they are at an address that is a multiple of 4 but not 8. Not really sure what to make of this, anyone else know how we ought to fix this? This has actually been an issue for ages, most commonly seen with doubles. take a look at the thread at http://www.freebsd.org/cgi/getmsg.cgi?fetch=393691+0+/usr/local/www/db/text/2000/freebsd-current/2507.freebsd-current or, easier to read the entire thread: http://groups.yahoo.com/group/freebsd-current/messages/39583?threaded=1 -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues (was: unbelievable benchmark output)
In message [EMAIL PROTECTED], Dan Nelson cleopede: In the last episode (Feb 03), Alfred Perlstein said: * Michal Mertl [EMAIL PROTECTED] [020203 08:17] wrote: Not really sure what to make of this, anyone else know how we ought to fix this? This has actually been an issue for ages, most commonly seen with doubles. take a look at the thread at Has any real world program ever been significantly affected by this problem? Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
