From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-116315-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 29248 invoked by alias); 24 Jun 2005 22:17:08 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 29238 invoked by uid 22791); 24 Jun 2005 22:17:05 -0000
Received: from mail-out2.fuse.net (HELO smtp2.fuse.net) (216.68.8.175)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 22:17:05 +0000
Received: from gx6.fuse.net ([216.68.17.142]) by smtp2.fuse.net
          (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP
          id <20050624221703.BLBP10827.smtp2.fuse.net@gx6.fuse.net>
          for <gcc@gcc.gnu.org>; Fri, 24 Jun 2005 18:17:03 -0400
Received: from dellpi.pinski.fam ([216.68.17.142]) by gx6.fuse.net
          (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP
          id <20050624221702.IDRD22079.gx6.fuse.net@dellpi.pinski.fam>;
          Fri, 24 Jun 2005 18:17:02 -0400
Received: from [10.0.0.80] (zhivago.i.pinski.fam [10.0.0.80])
	by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id j5OMGvQi007120;
	Fri, 24 Jun 2005 18:16:58 -0400 (EDT)
In-Reply-To: <B7C12C01-DBA8-4F56-9DF3-4BE0C45D5ADD@apple.com>
References: <B7C12C01-DBA8-4F56-9DF3-4BE0C45D5ADD@apple.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <91fc834a41b6161b507a2a714c7b867a@physics.uc.edu>
Content-Transfer-Encoding: 7bit
Cc: gcc@gcc.gnu.org
From: Andrew Pinski <pinskia@physics.uc.edu>
Subject: Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86
Date: Fri, 24 Jun 2005 22:17:00 -0000
To: Fariborz Jahanian <fjahanian@apple.com>
X-SW-Source: 2005-06/txt/msg01026.txt.bz2


On Jun 24, 2005, at 6:07 PM, Fariborz Jahanian wrote:

> A source file mrSurfaceList.cc of 252.eon produces less efficient code 
> initializing instance objects to 0 at -O2 than at -O1. Behavior is 
> random and it does not happen on all x86  platforms and making the 
> test smaller makes the problem go away. But here is what I found out 
> is the cause.
>

> This cannot be simplified by fold_rtx, resulting in less efficient 
> code.

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;
}

Thanks,
Andrew Pinski