Re: PATCH: fine-tuning for can_store_by_pieces

[Richard Sandiford <richard@codesourcery.com>]

I'll leave the target-independent bits to the appropriate maintainers.
As far as the MIPS bits go:

Sandra Loosemore <sandra@codesourcery.com> writes:
> + /* Define MOVE_RATIO to encourage use of movmemsi when enabled,
> +    since it should always generate code at least as good as
> +    move_by_pieces().  But when inline movmemsi pattern is disabled
> +    (i.e., with -mips16 or -mmemcpy), instead represent the length of
> +    a memcpy call sequence (~6 insns), so that move_by_pieces will
> +    generate inline code if it is shorter than a function call.
> +    Note that move_by_pieces_ninsns() counts memory-to-memory moves,
> +    but we'll have to generate a load/store pair for each, so further
> +    halve the value to take that into account.  */
> + 
> + #define MOVE_RATIO ((TARGET_MIPS16 || TARGET_MEMCPY) ? 3 : 2)

The TARGET_MIPS16 || TARGET_MEMCPY case is fine, and nicely described,
but it would be good to have a comment explaining why 2 encourages
"use of movmemsi when enabled".

> + /* For CLEAR_RATIO use a better estimate of the length of a memset
> +    call when optimizing for size.  */
> + 
> + #define CLEAR_RATIO	(optimize_size ? 5 : 15)

Might be worth emphasising that 15 is the default for !optimize_size,
as it otherwise isn't clear where that number came from.

> + /* 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.)

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

> + /* 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?

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.)

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.

Richard