On 10/12/2011 10:13 AM, Tom de Vries wrote:
> On 10/10/2011 05:50 PM, Eric Botcazou wrote:
>>> So, the patch for build_constant_desc does not have the desired effect.
>>
>> OK, too bad that we need to play this back-and-forth game with MEMs. So the
>> original patch is OK (with TREE_READONLY (bas
On 10/10/2011 05:50 PM, Eric Botcazou wrote:
>> So, the patch for build_constant_desc does not have the desired effect.
>
> OK, too bad that we need to play this back-and-forth game with MEMs. So the
> original patch is OK (with TREE_READONLY (base) on the next line to mimic
> what
> is done j
> So, the patch for build_constant_desc does not have the desired effect.
OK, too bad that we need to play this back-and-forth game with MEMs. So the
original patch is OK (with TREE_READONLY (base) on the next line to mimic what
is done just above and without the gcc/ prefix in the ChangeLog).
On 10/10/2011 03:44 PM, Eric Botcazou wrote:
>> The patch makes sure that the src_mem computed here in
>> expand_builtin_memcpy is marked as MEM_READONLY_P:
>> ...
>> src_mem = get_memory_rtx (src, len);
>> ...
>>
>> build and reg-tested on i686, arm, and mips.
>>
>> OK for trunk?
>
> Do you
> The patch makes sure that the src_mem computed here in
> expand_builtin_memcpy is marked as MEM_READONLY_P:
> ...
> src_mem = get_memory_rtx (src, len);
> ...
>
> build and reg-tested on i686, arm, and mips.
>
> OK for trunk?
Do you get the same result by calling gen_const_mem from build_c
Eric,
without this patch, the mips code for the memcpy test-case in the patch looks
like this. The loadbytes (lbu) and the storebytes (sb) are considered to alias,
so the scheduler cannot rearrange them in a more optimal order.
...
lui $2,%hi($LC0)
lbu $3,%lo($LC0)($2)
