From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1081 invoked by alias); 30 Jun 2005 16:04:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1027 invoked by uid 22791); 30 Jun 2005 16:04:33 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 30 Jun 2005 16:04:33 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5UG4V3E000566 for ; Thu, 30 Jun 2005 09:04:31 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 30 Jun 2005 09:04:31 -0700 Received: from [17.219.198.46] ([17.219.198.46]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j5UG4T6L017659; Thu, 30 Jun 2005 09:04:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <71AD0926-2DA8-4B55-828F-38A85155CC86@apple.com> References: <6269B965-AF17-4FBD-B3ED-B1BA96936380@apple.com> <20050627195619.GA12102@redhat.com> <71AD0926-2DA8-4B55-828F-38A85155CC86@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27918F7A-CBBC-4657-AB29-3242BE6DF53D@apple.com> Cc: Richard Henderson , gcc@gcc.gnu.org Content-Transfer-Encoding: 7bit From: fjahanian Subject: Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86 Date: Thu, 30 Jun 2005 16:04:00 -0000 X-SW-Source: 2005-06/txt/msg01309.txt.bz2 On Jun 27, 2005, at 2:50 PM, Fariborz Jahanian wrote: > > On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote: > > >> Hmm. I would suspect this is obsolete now. We'll have forced >> everything into "registers" (or something equivalent that we >> can work with) during tree optimization. Any CSEs that can be >> made should have been made. >> >> > > I will do sanity check followed by SPEC runs (x86 and ppc darwin) > and see if behavior changes by obsoleting -fforce-mem in -O2 (or > higher). Bootstrapped and dejagnu tested on apple-x86-darwin and apple-ppc- darwin. We also observed that on ppc, SPEC did not show any performance change either way. On apple-x86-darwin 252.eon improved by 7% as expected, with no noticeable change in other benchmarks. One caveat to all these is that this may expose optimization bugs which were previously hidden by inclusion of -fforce-mem. OK for check-in? - fariborz ChangeLog: 2005-06-30 Fariborz Jahanian * opts.c (decode_options): Don't set -fforce-mem with -O2 and more. Index: opts.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/opts.c,v retrieving revision 1.114 diff -c -p -r1.114 opts.c *** opts.c 24 Jun 2005 03:09:45 -0000 1.114 --- opts.c 30 Jun 2005 15:55:15 -0000 *************** decode_options (unsigned int argc, const *** 559,565 **** flag_rerun_cse_after_loop = 1; flag_rerun_loop_opt = 1; flag_caller_saves = 1; - flag_force_mem = 1; flag_peephole2 = 1; #ifdef INSN_SCHEDULING flag_schedule_insns = 1; --- 559,564 ---- > > - Thanks, fariborz > > >> >> r~ >> >> > >