[PATCH] Make mempcpy more optimal (PR middle-end/70140).

[Martin Liška]

On 08/02/2017 09:16 AM, Jakub Jelinek wrote:
> On Wed, Aug 02, 2017 at 09:13:40AM +0200, Martin Liška wrote:
>> On 08/01/2017 09:50 PM, Jakub Jelinek wrote:
>>> On Thu, Jul 20, 2017 at 08:59:29AM +0200, Martin Liška wrote:
>>>> Hello.
>>>>
>>>> Following patch does sharing of expansion for mem{p,}cpy and also strpcy (with a known constant as source)
>>>> so that we use same type of expansion (direct insns emission, direct emission with a loop instruction and
>>>> library call). As mentioned in the PR, glibc does not provide an optimized version for majority of targets.
>>>>
>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>>
>>> This broke e.g.
>>> FAIL: gcc.dg/20050503-1.c scan-assembler-not call
>>> on i686-linux, the result is significantly worse.
>>> Also, while perhaps majority of targets don't provide optimized version,
>>> some targets do, including i?86/x86_64, and if the memcpy would be expanded
>>> as a call, it is much better to just emit mempcpy call instead.
>>> Just look at the testcase, because of this misoptimization we suddenly can't
>>> use a tail call.
>>>
>>> 	Jakub
>>>
>>
>> I see. That said, should I introduce some target hook that will tell whether to expand to
>> 'return memcpy(dst, src,l) + dst;' or call library mempcpy routine?
> 
> If some targets aren't willing to provide fast mempcpy in libc, then yes I
> guess.  And, for -Os you should never do the former, that isn't going to be
> shorter (at least unless the memcpy is expanded inline and is shorter than
> the call + addition).

Good, I will work on that.

> 
> BTW, do we have folding of mempcpy to memcpy if the result is ignored (no
> lhs)?

Yes, we do it, I've just verified that.

Martin

> 
> 	Jakub
>