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 (base) on the
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 just
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)
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
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 get the same
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).
