Re: PATCH: fine-tuning for can_store_by_pieces

[Sandra Loosemore <sandra@codesourcery.com>]

Richard Sandiford wrote:

>> + /* This is similar to CLEAR_RATIO, but for a non-zero constant, so when
>> +    optimizing for size adjust the ratio to account for the overhead of
>> +    loading the constant and replicating it across the word.  In fact in
>> +    that case it is never worth inlining, since calling memset should
>> +    always be smaller.  */
>> + 
>> + #define SET_RATIO	(optimize_size ? 3 : 15)
> 
> Is there a lower limit to the size of memsets for which SET_RATIO is
> used?  I'm not convinced that memset is smaller for power-of-2 stores up
> to word or (if aligned) doubleword size.  (I'm assuming here that we use
> left/right stores for unaligned 4-byte and (on 64-bit targets) 8-byte
> stores.  If we don't, we should.)

This is being handled by the non-target-specific code in builtins.c.  If 
optimize_size is true, it won't even consider can_store_by_pieces if the byte 
count is greater than 1, and the next alternative it tries is setmem.

> Perhaps one of these days we should add a setmem pattern...

Uh, yeah.  :-)  For optimize_size, it looks like it would be a win over the 
libcall to memset in the case where the buffer is properly aligned for an 
integer move and the value is a constant.  For a non-constant value, there's the 
extra overhead of replicating it across the word, as noted in the comment above.

>> + /* STORE_BY_PIECES_P can be used when copying a constant string, but
>> +    in that case each word takes 3 insns (lui, ori, sw), or more in
>> +    64-bit mode, instead of 2 (lw, sw). So better to always fail this
>> +    and let the move_by_pieces code copy the string from read-only
>> +    memory.  */
>> + 
>> + #define STORE_BY_PIECES_P(SIZE, ALIGN) 0
> 
> However, lui/ori/sw could easily be better speedwise in some situations,
> so should this be dependent on optimize_size too?

Ermmm.  In what "some situations" would it better?

> Finally, a general comment: the call costs seem to be based on *-elf
> targets, where a direct call is allowed.  The cost of a call is higher
> sizewise for n32 and n64 abicalls.  It is higher still for o32 abicalls,
> where we have to restore $gp afterwards.  (The cost for all three is even
> higher if the function didn't otherwise need $gp, but I don't think we
> can really account for that.)

I can figure this out by trial and error, of course, but do you (or Nigel, etc) 
know offhand what the cost adjustments should be for each ABI?

> Please check whether this patch fixes PR 11787.  (It should, if the
> cost are good.)  If it does, add "PR target/11787" to the changelog.

Yes, it looks like it does fix that issue.  I will mark the ChangeLog for the 
next version of the patch.

-Sandra