From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15950 invoked by alias); 30 Jun 2005 15:03:08 -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 15860 invoked by uid 22791); 30 Jun 2005 15:02:49 -0000 Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 30 Jun 2005 15:02:49 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j5UF19AY022198 for ; Thu, 30 Jun 2005 08:01:10 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 30 Jun 2005 08:01:09 -0700 Received: from [17.219.196.159] ([17.219.196.159]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j5UF18ZO019106; Thu, 30 Jun 2005 08:01:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <4B4BAEC7-6348-4408-B415-F6B6788C7374@apple.com> References: <91fc834a41b6161b507a2a714c7b867a@physics.uc.edu> <200506250206.23245.stevenb@suse.de> <4B4BAEC7-6348-4408-B415-F6B6788C7374@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0654E1F2-FAF8-4695-B4A6-F374520D1D0E@apple.com> Cc: Steven Bosscher , 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 15:03:00 -0000 X-SW-Source: 2005-06/txt/msg01306.txt.bz2 On Jun 24, 2005, at 5:20 PM, fjahanian wrote: > > On Jun 24, 2005, at 5:06 PM, Steven Bosscher wrote: > > >> On Saturday 25 June 2005 01:48, fjahanian wrote: >> >> >>> On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote: >>> >>> >>>> I wonder why combine can do the simplification though which is why >>>> still >>>> produce good code for the simple testcase: >>>> void f1(double *d,float *f2) >>>> { >>>> *f2 = 0.0; >>>> *d = 0.0; >>>> } >>>> >>>> >>> >>> It is hard to reproduce the simple test case, exhibiting the same >>> problem (-O1 producing better code than -O2). Yes, small test cases >>> move the desired simplification to other phases. >>> >>> >> >> It often helps if you know what function your poorer code is in. You >> could e.g. try to make the .optimized dump of that function >> compilable >> and see if the problem shows up there again. Then work your way down >> to something small. >> > > Yes, I am planning to do this. My first question was though if the > RTL generated by -O2, which does not get simplified, is correct and > should be optimized in one of the rtl optimizers. If not, then > focus shifts to tree optimizers. This email went through late and superseded by earlier exchanges, It turned out to be all RTL related issues. - faribrz > > - Thanks ,fariborz > > >> >> Gr. >> Steven >> >> >> > >