From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12959 invoked by alias); 21 Aug 2007 14:18:39 -0000 Received: (qmail 12865 invoked by uid 22791); 21 Aug 2007 14:18:37 -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 14:18:29 +0000 Received: (qmail 23302 invoked from network); 21 Aug 2007 14:18:27 -0000 Received: from unknown (HELO gateway) (10.0.0.100) by mail.codesourcery.com with SMTP; 21 Aug 2007 14:18:27 -0000 Received: by gateway (Postfix, from userid 1010) id C82376C0CC; Tue, 21 Aug 2007 07:18:26 -0700 (PDT) From: Richard Sandiford To: Sandra Loosemore Mail-Followup-To: Sandra Loosemore ,GCC Patches , Nigel Stephens , Guy Morrogh , David Ung , Thiemo Seufer , Mark Mitchell , richard@codesourcery.com Cc: GCC Patches , Nigel Stephens , Guy Morrogh , David Ung , Thiemo Seufer , Mark Mitchell 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> <46CAEBCE.3050807@codesourcery.com> Date: Tue, 21 Aug 2007 14:22:00 -0000 In-Reply-To: <46CAEBCE.3050807@codesourcery.com> (Sandra Loosemore's message of "Tue\, 21 Aug 2007 09\:42\:38 -0400") Message-ID: <87r6lx3r9p.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg01368.txt.bz2 Sandra Loosemore writes: > 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. Hmm, I'm not sure I follow. You seem to be implying that 1-byte stores are always done "by pieces" when optimize_size, but I don't think that's true. I was referring the 1-instruction bound in code like this: if (host_integerp (len, 1) ---> && !(optimize_size && tree_low_cst (len, 1) > 1) && can_store_by_pieces (tree_low_cst (len, 1), builtin_memset_read_str, &c, dest_align)) { val_rtx = force_reg (TYPE_MODE (unsigned_char_type_node), val_rtx); store_by_pieces (dest_mem, tree_low_cst (len, 1), builtin_memset_gen_str, val_rtx, dest_align, 0); } else if (!set_storage_via_setmem (dest_mem, len_rtx, val_rtx, dest_align, expected_align, expected_size)) goto do_libcall; This code still uses can_store_by_pieces for single-byte stores when optimize_size (and can still fall back to setmem or libcalls for that case if can_store_by_pieces returns false, although I agree that's an odd thing to do for single-byte stores). What I was objecting to was that the target doesn't get any chance to say that _2-byte stores_ (or bigger) are better implemented "by pieces" than via a setmem or libcall pattern. You referred to this limit yourself when I queried the MIPS optimize_size value of SET_RATIO. You said that the value only really matters for 1-byte stores, and looking at the patch, I thought I could see why. All calls to can_store_by_pieces with a "true" argument seemed to be guarded by a check like the above. So the suggestion to move the check was really following on from that. As far as I could tell, CLEAR_RATIO and CLEAR_BY_PIECES_P have no single-byte limit for optimize_size, so I was thinking it would be better if SET_RATIO and SET_BY_PIECES_P didn't either. Richard