This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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).

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]