Re: PATCH: fine-tuning for can_store_by_pieces

[Nigel Stephens <nigel@mips.com>]

Sandra Loosemore wrote:
> Andrew Pinski wrote:
>> On 8/15/07, Sandra Loosemore <sandra@codesourcery.com> wrote:
>>> On MIPS we can get better code by having can_store_by_pieces 
>>> differentiate
>>> between the cases where it's used for memset operations, and those 
>>> where it's
>>> used to copy a string constant.  This patch introduces new SET_RATIO 
>>> and
>>> SET_BY_PIECES_P macros, with appropriate defaults to preserve the 
>>> existing
>>> behavior.  I checked other targets and made the ones that override 
>>> the default
>>> STORE_BY_PIECES_P clone the same definition for SET_BY_PIECES_P.
>>
>> Are you sure that the cause of the real issue here is not really PR
>> 31150?  
>
> I don't think so.  Nigel originally developed this patch against gcc 
> 3.4; I just verified that it still does something useful for current 
> mainline.
>
>> I don't think copying string constants and memcpy/memset
>> should be different in terms of heuristics.
>>
>> It seems if you gave a testcase where this is profitable, it would be
>> better to judge this patch (and maybe a testcase for the testsuite
>> also).
>
> I'll see if I can come up with something specific, or perhaps Nigel 
> has a test case.

No I don't have a specific test case: it's not a failure case, but an 
optimisation.

Note that store_by_pieces is used for two different purposes: to copy 
string constants to memory (e.g.  __builtin_strcpy) or initialise local 
arrays, and also to set a memory buffer to a single constant value 
(__builtin_memset). IMHO the benefit computation of using a movstr 
versus expanding it inline does need to be different for each case, 
since on a 32-bit MIPS processor the strcpy gets expanded into a 
repeated sequence of three instructions (lui; ori; sw) where each 
immediate value is the next 4-byte chunk of the string; whereas in the 
second case the immediate value is computed only once, followed then by 
a sequence of "sw" instructions.

Nigel