RE: Gcc builtin review: strcpy, stpcpy, strcat, stpcat?

["Wilco Dijkstra" <wdijkstr at arm dot com>]

> OndÅej BÃlka wrote:
> On Thu, Jun 04, 2015 at 11:27:57AM +0100, Richard Earnshaw wrote:
> > On 25/05/15 12:45, OndÅej BÃlka wrote:
> > > Replaces it with strcpy. One could argue that opposite way to replace
> > > strcpy with stpcpy is faster.
> > >
> > > Reason is register pressure. Strcpy needs extra register to save return
> > > value while stpcpy has return value already in register used for writing
> > > terminating zero.
> >
> >
> > Depends on your architecture.  On aarch64 we have plenty of spare
> > registers, so strcpy simply copies the destination register into a
> > scratch.  It then doesn't have to carefully calculate the return value
> > at the end of the function (making the tail code simpler - there are
> > multiple return statements, but only one entry point).
> >
> Thats correct, main saving you get is from return value is first register, that
> forces needing extra copy which is suboptimal.

No you don't need an extra copy. The current AArch64 strcpy code doesn't do it, 
neither does my new strlen code, memcpy, memset or memmove. 
There is however an overhead in returning the last byte for stpcpy.

> I don't have data how strcpy and stpcpy mix and want to know if few
> extra cycles are worth it when these aren't called exactly often, I will
> try to think how test these.

The usual problem of knowing whether all targets define assembler versions of
stpcpy applies - so I don't think it is a good idea to change all strcpy into
stpcpy in general. The only useful case is strcpy(x,y)+strlen(x) which could 
potentially give a major speedup.

Wilco