public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard@codesourcery.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: 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>
Subject: Re: PATCH: fine-tuning for can_store_by_pieces
Date: Tue, 21 Aug 2007 20:56:00 -0000	[thread overview]
Message-ID: <87zm0k39gj.fsf@firetop.home> (raw)
In-Reply-To: <46CB4B99.5010501@codesourcery.com> (Sandra Loosemore's message 	of "Tue\, 21 Aug 2007 16\:31\:21 -0400")

Sandra Loosemore <sandra@codesourcery.com> writes:
> Richard Sandiford wrote:
>> 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.
>
> Oh, OK.  I misunderstood what you were unhappy about there.  I tried 
> just removing the offending clause of the if statement, and got a small 
> decrease in size across the board for CSiBE tests (just -Os, -Os 
> -mips16, and -Os -mabicalls) on mips32r2.
>
> I'm not sure it's necessary to move the optimize_size test to the 
> default definition of SET_RATIO.  We currently have:
>
> #ifndef MOVE_RATIO
> #if defined (HAVE_movmemqi) || defined (HAVE_movmemhi) || defined 
> (HAVE_movmemsi) || defined (HAVE_movmemdi) || defined (HAVE_movmemti)
> #define MOVE_RATIO 2
> #else
> /* If we are optimizing for space (-Os), cut down the default move 
> ratio.  */
> #define MOVE_RATIO (optimize_size ? 3 : 15)
> #endif
>
> #endif
> /* If a memory set (to value other than zero) operation would take
>     SET_RATIO or more simple move-instruction sequences, we will do a movmem
>     or libcall instead.  */
> #ifndef SET_RATIO
> #define SET_RATIO MOVE_RATIO
> #endif
>
> ...so SET_RATIO is already guaranteed to default to a small value if 
> optimize_size is true.  Only problem is if folks are concerned that this 
> change might be a Bad Thing for other back ends; all my other changes 
> have tried not to change the behavior on anything other than MIPS.

Ah, good point.  FWIW, as far as the MIPS port goes, just removing the
test would certainly be fine by me.  It's good to hear that it does
indeed bring about a size improvement.

Richard

  reply	other threads:[~2007-08-21 20:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-15 17:15 Sandra Loosemore
2007-08-15 17:22 ` Andrew Pinski
2007-08-15 18:32   ` Sandra Loosemore
2007-08-15 19:53     ` Nigel Stephens
2007-08-15 19:58   ` Sandra Loosemore
2007-08-17  4:50   ` Mark Mitchell
2007-08-17 13:24     ` Sandra Loosemore
2007-08-17 18:55       ` Mark Mitchell
2007-08-16  8:34 ` Richard Sandiford
2007-08-16 19:41   ` Sandra Loosemore
2007-08-19  0:03   ` Sandra Loosemore
2007-08-20  8:22     ` Richard Sandiford
2007-08-20 23:38       ` Sandra Loosemore
2007-08-21  8:21         ` Richard Sandiford
2007-08-21 10:34           ` Nigel Stephens
2007-08-21 11:53             ` Richard Sandiford
2007-08-21 12:14               ` Nigel Stephens
2007-08-21 12:35                 ` Richard Sandiford
2007-08-21 13:54           ` Sandra Loosemore
2007-08-21 14:22             ` Richard Sandiford
2007-08-21 20:39               ` Sandra Loosemore
2007-08-21 20:56                 ` Richard Sandiford [this message]
2007-08-23 14:35                   ` Sandra Loosemore
2007-08-23 14:44                     ` Richard Sandiford
2007-08-25  5:35                       ` [committed] " Sandra Loosemore
2007-08-25  9:18                         ` Jakub Jelinek
2007-08-25  9:58                           ` Jakub Jelinek
2007-08-25 14:30                           ` gcc.c-torture/execute/20030221-1.c regressed with "fine-tuning for can_store_by_pieces" Hans-Peter Nilsson
2007-08-25 14:40                           ` [committed] Re: PATCH: fine-tuning for can_store_by_pieces Sandra Loosemore
2007-08-24 22:06                     ` Mark Mitchell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zm0k39gj.fsf@firetop.home \
    --to=richard@codesourcery.com \
    --cc=davidu@mips.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=guym@mips.com \
    --cc=mark@codesourcery.com \
    --cc=nigel@mips.com \
    --cc=sandra@codesourcery.com \
    --cc=ths@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).