This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657, take 2)
On April 13, 2018 12:35:54 AM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>On Thu, Apr 12, 2018 at 07:37:22PM +0200, Jakub Jelinek wrote:
>> On Thu, Apr 12, 2018 at 05:29:35PM +0000, Wilco Dijkstra wrote:
>> > > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy
>got added,
>> > > in 2013 other power versions, in 2016 s390*, etc. Doing a decent
>mempcpy
>> > > isn't hard if you have asm version of memcpy and one spare
>register.
>> >
>> > More mempcpy implementations have been added in recent years
>indeed, but almost all
>> > add an extra copy of the memcpy code rather than using a single
>combined implementation.
>> > That means it is still better to call memcpy (which is frequently
>used and thus likely in L1/L2)
>> > rather than mempcpy (which is more likely to be cold and thus not
>cached).
>>
>> That really depends, usually when some app uses mempcpy, it uses it
>very
>> heavily. And all the proposed patches do is honor what the user
>asked, if
>> you use memcpy () + n, we aren't transforming that into mempcpy
>behind the
>> user's back.
>>
>> Anyway, here is what I think Richard was asking for, that I'm
>currently
>> bootstrapping/regtesting. It can be easily combined with Martin's
>target
>> hook if needed, or do it only for
>> endp == 1 && target != const0_rtx && CALL_EXPR_TAILCALL (exp)
>> etc.
>>
>> 2018-04-12 Martin Liska <mliska@suse.cz>
>> Jakub Jelinek <jakub@redhat.com>
>>
>> PR middle-end/81657
>> * expr.h (enum block_op_methods): Add BLOCK_OP_NO_LIBCALL_RET.
>> * expr.c (emit_block_move_hints): Handle BLOCK_OP_NO_LIBCALL_RET.
>> * builtins.c (expand_builtin_memory_copy_args): Use
>> BLOCK_OP_NO_LIBCALL_RET method for mempcpy with non-ignored target,
>> handle dest_addr == pc_rtx.
>>
>> * gcc.dg/string-opt-1.c: Remove bogus comment. Expect a mempcpy
>> call.
>
>Successfully bootstrapped/regtested on x86_64-linux and i686-linux.
OK.
Thanks,
Richard.
> Jakub