Date: Mon, 03 Mar 97 06:27:37 -0800 From: "That Doug Guy" <tiller@connectnet.com> To: "FreeBSD Questions" <FreeBSD-Questions@freebsd.org> Cc: "Jake Hamby" <jehamby@lightside.com> Subject: Good kernel compile options? (Was: Re: RSA 56-bit key challenge) Message-ID: <199703031428.GAA23640@smtp.connectnet.com>
next in thread | raw e-mail | index | archive | help
On Sun, 2 Mar 1997 18:42:56 -0800, Jake Hamby wrote: >Guy Helmer writes: >> That might help explain some of the differences in numbers for my runs of >> SPEC95 fp benchmarks on 2.1.5 (-O2 optimization) w/o HAVE_FPU math libs >> vs. 2.2-BETA (-O4 optimization) w/ HAVE_FPU. I ran a few of the fp >> benchmarks on 2.2 to compare to my full run under 2.1.5 and found the >> codes ran from slightly faster to much slower under 2.2. I figured it was >> due to the different math library, but maybe the compiler is more at fault >> than I thought... > >Maybe this has to do with the patch in 2.7.2.1 to disable certain kinds of >strength reduction (-fstrength-reduce) because of buggy code generation. Recall >that this bug was why FreeBSD changed from using -O2 to -O optimization >(although some people used "-O2 -fno-strength-reduce). So is this a good option to put in for COPTFLAGS in /etc/make.conf for maximum kernel efficiency with a 2.2-Gamma system? Something like: COPTFLAGS= -O2 -fno-strength-reduce -pipe I searched the gcc man page and found -fstrength-reduce but no explicit reference to the negation option. Is this still a valid flag in 2.7.2.1, or does the below indicate that this action is automatic now? Thanks, Doug >Here's a quote from >David S. Miller, from the "Sun vs. GCC" thread last month: > >> Also, the various optimizer bugs in GCC in the past have led people >> to be wary to use -O2 optimization, much less try additional >> optimization flags. >> >>I know about them, just about all of them are in the strength >>reduction pass. I am very familiar with the problematic bugs this >>layer has, and I have been actively trying to get people on the GCC >>development team to fix them. Almost all of these problems have to do >>with when a pointer comparison is converted into an integer invariant >>comparison, and vice versa. GCC in certain circumstances does not >>notice the change in signed'ness and thus produces incorrect code. In >>gcc-2.7.2.1, the strength reduction transformations that were known to >>lead to this situation were disabled entirely and in fact this fix was >>the entire reason for that release of gcc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703031428.GAA23640>