Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 08:58:36PM -0800, Doug Barton wrote: > On Sun, 9 Feb 2003, Bernd Walter wrote: > > > I'm always compiling -current on alpha and i386 with -O2 since months. > > I havn't noticed any compiler related problems lately. > > How do you know? It's not that I don't know about things that I have noticed. Of course I don't know if there are unnoticed problems, but there will be much more than just compiler bugs. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sun, 9 Feb 2003, Bernd Walter wrote: > I'm always compiling -current on alpha and i386 with -O2 since months. > I havn't noticed any compiler related problems lately. How do you know? -- "The last time France wanted more evidence, it rolled right through Paris with a German flag." - David Letterman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
Marcin Dalecki wrote: > David Schultz wrote: > > Strangely, gcc in FreeBSD 5.0 actually generates *slower* code > > when compiling for more recent architectures than when compiling > > for a 386. I don't know whether that is a bug in gcc or whether > > gcc is using some fancy feature like SSE that the kernel handles > > poorly on context switches. I think there was some discussion on > > the lists about it earlier. > > The reason is that the optimization done by GCC are ill balanced. > All the scheduling of instractions and what a not - which would be > fine on a micro scope level is causing so much higher pressure > on the CPUs caches that the code is actually loosing. That's not actually it, though there *are* instruction scheduling issues that will impact the Pentium 4 code generation, and other Intel processor-specific code generation, mostly L1 caches have been, relative to the size of main memory, been getting much, much larger. Intel has written an article on "How to generate optimized code for Pentium 4 processors". It has been posted to these lists a couple of times already, and you can search it out on Intel's site, if you care to. For the Pentium 4, the article identifies a shopping list of things that you are "not supposed to do", which GCC does. Actually, cache pressure is the least of them. If FreeBSD would cache line align locks and mutexes, and not put them in the same cache lines (very hard to do, for some structures), most of the so-called "cache pressure" could be made to "go away". IBM recently posted an article comparing performance numbers for Linux with and without this change. Realize, though, that FreeBSD and Linux have somewhat different philosophies when it comes to SMP, even if that's hard to tell from the lack of detailed implementation plans being published by either camp. If the ability to optimize code for the Pentium 4 concerns you, then you should become a contributor to the GCC project, which means you need to execute a notarized assignment of rights statement with the FSF before they will accept patches from you, and once that's done, you can start going down Intel's optimization laundry list, sending patches to the GCC folks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
David Schultz wrote: Thus spake Marcin Dalecki <[EMAIL PROTECTED]>: David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. Interesting. So they redid the code generation for gcc 3 and their new tricks backfired. But at least they fixed the completely braindead things gcc 2.9x was doing with alignment, floating point, and combinations thereof, and they got the compiler to do more reasonable things on ia64. Any idea when they will have fixed the i386 anti-optimizations? Well one of the aims seems currently to fix the most hideous design idiocy inside GCC. Namely: optimizing on the code generation level only instead of the parse tree. However at the current speed of things they will maybe only in about 10 years there. It would make much more sense to support efforts like www.tendra.org or www.openwatcom.org instead of giving any kind of hope to GCC. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003 at 04:25:42PM -0800, David Schultz wrote: > Yes, the possibility of being bitten by compiler bugs is certainly > higher with higher optimization levels. Alpha with -O2 seems to > have been broken for years, and I have seen strange things happen > on IA64 as well. But the i386 code generators have received much > wider testing and debugging, so there is somewhat less danger there. I'm always compiling -current on alpha and i386 with -O2 since months. I havn't noticed any compiler related problems lately. But I never used CPUTYPE over 586/mmx and ev56 as my -current machines end here. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003, David Schultz wrote: > > Yet squid under i386 freebsd is .. well, finds -O bugs in gcc. > > We gave up trying -O under FreeBSD a long time ago. :-) > > The last time someone told me, ``gcc -O is broken'', it turned out > that they were doing some stack fiddling, and gcc's optimizations > broke their faulty assumptions. On the other hand, I'm sure gcc -O > does have bugs. Do you have an example snippet that gets miscompiled? Err, grab the squid24 port, hack the configure script to remove the bit where it removes -O for FreeBSD, compile, install, run. It should die quite quickly after you submit a HTTP request which requires a DNS lookup - GCC generates an xor %eax, %eax at the beginning of a function which NULLs a pointer - that we're not NULLing. :-) Adrian -- Adrian Chadd learning is bad <[EMAIL PROTECTED]> it just makes the people around you dumber (angryskul == alfred@irc):( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
Thus spake Marcin Dalecki <[EMAIL PROTECTED]>: > David Schultz wrote: > > >Strangely, gcc in FreeBSD 5.0 actually generates *slower* code > >when compiling for more recent architectures than when compiling > >for a 386. I don't know whether that is a bug in gcc or whether > >gcc is using some fancy feature like SSE that the kernel handles > >poorly on context switches. I think there was some discussion on > >the lists about it earlier. > The reason is that the optimization done by GCC are ill balanced. > All the scheduling of instractions and what a not - which would be > fine on a micro scope level is causing so much higher pressure > on the CPUs caches that the code is actually loosing. Interesting. So they redid the code generation for gcc 3 and their new tricks backfired. But at least they fixed the completely braindead things gcc 2.9x was doing with alignment, floating point, and combinations thereof, and they got the compiler to do more reasonable things on ia64. Any idea when they will have fixed the i386 anti-optimizations? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
Thus spake Adrian Chadd <[EMAIL PROTECTED]>: > On Sat, Feb 08, 2003, David Schultz wrote: > > > Yes, the possibility of being bitten by compiler bugs is certainly > > higher with higher optimization levels. Alpha with -O2 seems to > > have been broken for years, and I have seen strange things happen > > on IA64 as well. But the i386 code generators have received much > > wider testing and debugging, so there is somewhat less danger there. > > Yet squid under i386 freebsd is .. well, finds -O bugs in gcc. > We gave up trying -O under FreeBSD a long time ago. :-) The last time someone told me, ``gcc -O is broken'', it turned out that they were doing some stack fiddling, and gcc's optimizations broke their faulty assumptions. On the other hand, I'm sure gcc -O does have bugs. Do you have an example snippet that gets miscompiled? > (note: I've seen better performance gains by telling gcc exactly what > CPU you have over -O65536 ..) Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
"Jacques A. Vidrine" wrote: > On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote: > > The compiler > > didn't complain when he checked it before committing it because > > optimization was off by default; it should have complained, e.g.: > > Is that really what you meant? I don't believe it has anything to > do with optimization; rather, it is to do with lack of `warning' > flags. For example, if you build libc with WARNS=5 (so as to get the > `-Wuninitialized' flag), then you get this warning. > > > "x.c:9:warning: `foo' might be used uninitialized in this function" Uh... cc -Wall -Wuninitialized -O0 x.c "cc1: warning: -Wuninitialized is not supported without -O" 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 03:17:12PM +0100, Erik Trulsson wrote:
> On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
> > On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
> > > The compiler
> > > didn't complain when he checked it before committing it because
> > > optimization was off by default; it should have complained, e.g.:
> >
> > Is that really what you meant? I don't believe it has anything to
> > do with optimization; rather, it is to do with lack of `warning'
> > flags. For example, if you build libc with WARNS=5 (so as to get the
> > `-Wuninitialized' flag), then you get this warning.
> >
> > > "x.c:9:warning: `foo' might be used uninitialized in this function"
>
> Some warnings are not generated unless you compile with optimization
> on. The reason for this is that to generate some of the warnings (for
> example about uninitialized variables) you need to do some dataflow
> analysis and gcc only does this when optimizing.
>
> Take for example this little program:
>
> #include
> int main(void)
> {
> int a;
> printf("%d\n",a);
> return 0;
> }
>
> When compiled using 'gcc -O0 -Wall' no warnings are generated. When
> compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
> uninitalized. (This is the case for gcc 2.95.x at least. I believe the
> situation is the same with gcc 3.x)
Ah, I see. Yes, it is the case with gcc 3.x.
cc1: warning: -Wuninitialized is not supported without -O
I don't think I ever knew that.
I should have tried it before posting, but the comment that the
problem was that `optimization was off by default' threw me --- it is
ON by default.
Cheers,
--
Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
> On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
> > The compiler
> > didn't complain when he checked it before committing it because
> > optimization was off by default; it should have complained, e.g.:
>
> Is that really what you meant? I don't believe it has anything to
> do with optimization; rather, it is to do with lack of `warning'
> flags. For example, if you build libc with WARNS=5 (so as to get the
> `-Wuninitialized' flag), then you get this warning.
>
> > "x.c:9:warning: `foo' might be used uninitialized in this function"
Some warnings are not generated unless you compile with optimization
on. The reason for this is that to generate some of the warnings (for
example about uninitialized variables) you need to do some dataflow
analysis and gcc only does this when optimizing.
Take for example this little program:
#include
int main(void)
{
int a;
printf("%d\n",a);
return 0;
}
When compiled using 'gcc -O0 -Wall' no warnings are generated. When
compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
uninitalized. (This is the case for gcc 2.95.x at least. I believe the
situation is the same with gcc 3.x)
--
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003, David Schultz wrote: > Yes, the possibility of being bitten by compiler bugs is certainly > higher with higher optimization levels. Alpha with -O2 seems to > have been broken for years, and I have seen strange things happen > on IA64 as well. But the i386 code generators have received much > wider testing and debugging, so there is somewhat less danger there. Yet squid under i386 freebsd is .. well, finds -O bugs in gcc. We gave up trying -O under FreeBSD a long time ago. :-) (note: I've seen better performance gains by telling gcc exactly what CPU you have over -O65536 ..) Adrian -- Adrian Chadd learning is bad <[EMAIL PROTECTED]> it just makes the people around you dumber (angryskul == alfred@irc):( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote: > The compiler > didn't complain when he checked it before committing it because > optimization was off by default; it should have complained, e.g.: Is that really what you meant? I don't believe it has anything to do with optimization; rather, it is to do with lack of `warning' flags. For example, if you build libc with WARNS=5 (so as to get the `-Wuninitialized' flag), then you get this warning. > "x.c:9:warning: `foo' might be used uninitialized in this function" Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On 09-Feb-2003 Dan Nelson wrote: > In the last episode (Feb 08), Conrad Sabatier said: >> Call me a fool, but I've been using this for quite some time now, in both >> -stable (well, with slight modifications) and -current: >> >> CPUTYPE?=k7 >> >> CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ >> -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ >> -fexpensive-optimizations -fschedule-insns2 > > Have you actually tested the benefits of these switches? If you had, > you would have discovered that -fforce-mem, -fstrength-reduce, > -fthread-jumps, -fcse-follow-jumps, -fcse-skip-blocks, > -frerun-cse-after-loop, > -fexpensive-optimizations, and -fschedule-insns2 do absolutely nothing, since > -O2 enables them anyway. -fforce-addr is the only non-redundant -f flag in > that whole list. Yes, I figured some of them were redundant, but it was kind of hard to figure out which ones, so I just went ahead and used them. :-) -- Conrad Sabatier <[EMAIL PROTECTED]> - "In Unix veritas" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
In the last episode (Feb 08), Conrad Sabatier said: > Call me a fool, but I've been using this for quite some time now, in both > -stable (well, with slight modifications) and -current: > > CPUTYPE?=k7 > > CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ > -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ > -fexpensive-optimizations -fschedule-insns2 Have you actually tested the benefits of these switches? If you had, you would have discovered that -fforce-mem, -fstrength-reduce, -fthread-jumps, -fcse-follow-jumps, -fcse-skip-blocks, -frerun-cse-after-loop, -fexpensive-optimizations, and -fschedule-insns2 do absolutely nothing, since -O2 enables them anyway. -fforce-addr is the only non-redundant -f flag in that whole list. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On 08-Feb-2003 Ray Kohler wrote: > Has anyone tried building world/kernel with high optimizations (-O2, > -O3) recently? What breaks? (Booby prize to whoever says "common sense" > ;) I last tried it quite a few months ago and the resolver died on me, > don't know what else. I'm not really thinking of running like that, but > I am curious about others' experiences. Call me a fool, but I've been using this for quite some time now, in both -stable (well, with slight modifications) and -current: CPUTYPE?=k7 CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ -fexpensive-optimizations -fschedule-insns2 COPTFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ -fexpensive-optimizations -fschedule-insns2 My -current box seems to be remarkably stable (and fast!). Guess I must be living right. :-) -- Conrad Sabatier <[EMAIL PROTECTED]> - "In Unix veritas" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> David Schultz wrote:
> > Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> > > Actually, failure to use optimization suppresses some compilation
> > > warnings, particularly those which normally print from using some
> > > variables without initializing them.
> >
> > I think you're thinking of dataflow analysis, which I believe gcc
> > does with -O and higher optimization levels. So unless you're
> > using -O0, I would expect that you'd get all the warnings you
> > want.
>
> See the thread "Re: tmpfile breakage on setuid executables".
>
> Kris accidently introduced a bug that had to do with whether or
> not a variable was used before it was initialized. The compiler
> didn't complain when he checked it before committing it because
> optimization was off by default; it should have complained, e.g.:
>
> "x.c:9:warning: `foo' might be used uninitialized in this function"
Thanks, I saw that. I'm just pointing out that all you need is -O
to get that warning:
das@bloody-mary:~> cat foo.c
int main() {
int foo;
return foo;
}
das@bloody-mary:~> gcc -o foo foo.c -Wall -O
foo.c: In function `main':
foo.c:2: warning: `foo' might be used uninitialized in this function
This is one of those things that gcc3 does pretty well, but Sun's
javac does very badly. First of all, in Java, the above warning
is considered an error (except *maybe* in JDK 1.4, which is broken
and slow on IA64 so I can't use it). Second, the dataflow
analysis in javac is braindead, so the compiler is almost always
wrong. When I get the same warning from gcc, it's usually right
unless interprocedural analysis would be required.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
David Schultz wrote: > Thus spake Terry Lambert <[EMAIL PROTECTED]>: > > Actually, failure to use optimization suppresses some compilation > > warnings, particularly those which normally print from using some > > variables without initializing them. > > I think you're thinking of dataflow analysis, which I believe gcc > does with -O and higher optimization levels. So unless you're > using -O0, I would expect that you'd get all the warnings you > want. See the thread "Re: tmpfile breakage on setuid executables". Kris accidently introduced a bug that had to do with whether or not a variable was used before it was initialized. The compiler didn't complain when he checked it before committing it because optimization was off by default; it should have complained, e.g.: "x.c:9:warning: `foo' might be used uninitialized in this function" > > There are a number of places, particularly on non-i386 platforms, > > where optimization actually doesn't work. I think that's why it > > was turned off for the libc compilation, and why the bug crept in. > > > > It's probably useful to compile world with optimization occasionally, > > to make compilation-time detectable bugs like that to show up, but, as > > you point out, it'd probably be a *bad* idea to actually use the > > resulting code, at least until after the next GCC import, which will > > supposedly fix the Alpha optimizer. > > Yes, the possibility of being bitten by compiler bugs is certainly > higher with higher optimization levels. Alpha with -O2 seems to > have been broken for years, and I have seen strange things happen > on IA64 as well. But the i386 code generators have received much > wider testing and debugging, so there is somewhat less danger there. Yes. I just wanted to point out that what's probably a good idea for catching coding errors like uninitialized variables is definitely not a good idea for distributing code for people to run. I wasn't really sure why he was asking, so I tried to look at it from both angles. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
Thus spake Terry Lambert <[EMAIL PROTECTED]>: > David Schultz wrote: > > Thus spake Ray Kohler <[EMAIL PROTECTED]>: > > > Has anyone tried building world/kernel with high optimizations (-O2, > > > -O3) recently? What breaks? (Booby prize to whoever says "common sense" > > > ;) I last tried it quite a few months ago and the resolver died on me, > > > don't know what else. I'm not really thinking of running like that, but > > > I am curious about others' experiences. > > > > First, let me answer the question that you really meant to ask but > > forgot to, namely, ``How much of a performance difference does -O3 > > make over -O for the kernel/world?'' The answer is ``very little, > > for most purposes.'' So if you do use higher optimization levels, > > at least do a little benchmarking to make sure it was worth it. > > Actually, failure to use optimization suppresses some compilation > warnings, particularly those which normally print from using some > variables without initializing them. I think you're thinking of dataflow analysis, which I believe gcc does with -O and higher optimization levels. So unless you're using -O0, I would expect that you'd get all the warnings you want. > There are a number of places, particularly on non-i386 platforms, > where optimization actually doesn't work. I think that's why it > was turned off for the libc compilation, and why the bug crept in. > > It's probably useful to compile world with optimization occasionally, > to make compilation-time detectable bugs like that to show up, but, as > you point out, it'd probably be a *bad* idea to actually use the > resulting code, at least until after the next GCC import, which will > supposedly fix the Alpha optimizer. Yes, the possibility of being bitten by compiler bugs is certainly higher with higher optimization levels. Alpha with -O2 seems to have been broken for years, and I have seen strange things happen on IA64 as well. But the i386 code generators have received much wider testing and debugging, so there is somewhat less danger there. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
David Schultz wrote: > Thus spake Ray Kohler <[EMAIL PROTECTED]>: > > Has anyone tried building world/kernel with high optimizations (-O2, > > -O3) recently? What breaks? (Booby prize to whoever says "common sense" > > ;) I last tried it quite a few months ago and the resolver died on me, > > don't know what else. I'm not really thinking of running like that, but > > I am curious about others' experiences. > > First, let me answer the question that you really meant to ask but > forgot to, namely, ``How much of a performance difference does -O3 > make over -O for the kernel/world?'' The answer is ``very little, > for most purposes.'' So if you do use higher optimization levels, > at least do a little benchmarking to make sure it was worth it. Actually, failure to use optimization suppresses some compilation warnings, particularly those which normally print from using some variables without initializing them. We were just bit by this, the other day (search -current list archives for "zebras": mea maxima culpa). > To answer your second question, higher optimization levels usually > work, but there *will* be new bugs. I know of several libc > problems due to -fstrict-aliasing, and I'm told that the inline > assembly for TCP checksumming can still break. There are a number of places, particularly on non-i386 platforms, where optimization actually doesn't work. I think that's why it was turned off for the libc compilation, and why the bug crept in. It's probably useful to compile world with optimization occasionally, to make compilation-time detectable bugs like that to show up, but, as you point out, it'd probably be a *bad* idea to actually use the resulting code, at least until after the next GCC import, which will supposedly fix the Alpha optimizer. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
Thus spake Ray Kohler <[EMAIL PROTECTED]>: > Has anyone tried building world/kernel with high optimizations (-O2, > -O3) recently? What breaks? (Booby prize to whoever says "common sense" > ;) I last tried it quite a few months ago and the resolver died on me, > don't know what else. I'm not really thinking of running like that, but > I am curious about others' experiences. First, let me answer the question that you really meant to ask but forgot to, namely, ``How much of a performance difference does -O3 make over -O for the kernel/world?'' The answer is ``very little, for most purposes.'' So if you do use higher optimization levels, at least do a little benchmarking to make sure it was worth it. To answer your second question, higher optimization levels usually work, but there *will* be new bugs. I know of several libc problems due to -fstrict-aliasing, and I'm told that the inline assembly for TCP checksumming can still break. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
