From owner-freebsd-hackers Sun Apr 9 23:25:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (vpn.iscape.fi [195.170.146.67]) by hub.freebsd.org (Postfix) with ESMTP id 073E337B78F; Sun, 9 Apr 2000 23:25:09 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id JAA06909; Mon, 10 Apr 2000 09:19:07 +0300 (EEST) (envelope-from will) To: kris@FreeBSD.org (Kris Kennaway) Cc: hackers@FreeBSD.org Subject: Re: What are the best gcc optimization options for Pentium 200 MMX References: From: Ville-Pertti Keinonen Date: 10 Apr 2000 09:19:07 +0300 In-Reply-To: kris@FreeBSD.org's message of "9 Apr 2000 00:19:09 +0300" Message-ID: <86snwuwk9w.fsf@not.demophon.com> Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG kris@FreeBSD.org (Kris Kennaway) writes: > Can you say "gimmick"? :-) gcc often produces demonstrably broken code for > optimisation levels higher than -O. That -O is safe seems to be a persistent myth. GCC also produces broken code for -O and no optimization in some cases, sometimes while producing working code for higher optimization levels... I wouldn't state e.g. that -O2 produces broken code any more often than -O, this may have been true for version X.Y.Z but is certainly not universally true. I believe that the reasons the FreeBSD build uses -O are the fact that especially with older versions of gcc, -O2 slowed down compilation considerably for little noticable performance improvement (as for -O3, automatic inlining is generally undesirable), and it is always best to only have to test the system with a single set of flags. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message