From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-201931-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 32247 invoked by alias); 21 Aug 2007 13:45:59 -0000
Received: (qmail 32172 invoked by uid 22791); 21 Aug 2007 13:45:58 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 13:45:54 +0000
Received: (qmail 20993 invoked from network); 21 Aug 2007 13:45:52 -0000
Received: from unknown (HELO bullfrog.localdomain) (sandra@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 21 Aug 2007 13:45:52 -0000
Message-ID: <46CAEBCE.3050807@codesourcery.com>
Date: Tue, 21 Aug 2007 13:54:00 -0000
From: Sandra Loosemore <sandra@codesourcery.com>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
MIME-Version: 1.0
To: GCC Patches <gcc-patches@gcc.gnu.org>,   Nigel Stephens <nigel@mips.com>,  Guy Morrogh <guym@mips.com>, David Ung <davidu@mips.com>,   Thiemo Seufer <ths@mips.com>,  Mark Mitchell <mark@codesourcery.com>,  richard@codesourcery.com
Subject: Re: PATCH: fine-tuning for can_store_by_pieces
References: <46C3343A.5080407@codesourcery.com> <87ps1nop2x.fsf@firetop.home>	<46C778D6.5060808@codesourcery.com> <87y7g6r50c.fsf@firetop.home>	<46CA222D.2050107@codesourcery.com> <87ps1h5mda.fsf@firetop.home>
In-Reply-To: <87ps1h5mda.fsf@firetop.home>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2007-08/txt/msg01365.txt.bz2

Richard Sandiford wrote:

> What did you think about the other suggestion: moving the magic
> "1 instruction" bound for optimize_size from builtins.c to SET_RATIO?

Perhaps other maintainers can jump in and say something here, but my gut feeling 
is that it doesn't make sense to remove that.  Doing a one-byte store inline 
always has to be cheaper than a function call, and doing the optimization early 
makes more sense than relying on a target-specific expansion, because it might 
allow recognition of other optimization patterns along the way.  I found during 
my earlier testing that setting MOVE_RATIO too low to catch that case had the 
side-effect of causing one of the profile-guided optimization test cases to 
fail, for instance.

-Sandra