[PATCH] PowerPC: stpcpy optimization for PPC64/POWER7

[Steven Munroe]

On Wed, 2013-09-18 at 08:53 -0700, Richard Henderson wrote:
> On 09/18/2013 07:34 AM, Adhemerval Zanella wrote:
> > +	extrdi.	rTMP, rALT, 8, 0
> > +	stbu	rTMP, 8(rRTN)
> > +	beqlr
> > +	extrdi.	rTMP, rALT, 8, 8
> > +	stbu	rTMP, 1(rRTN)
> > +	beqlr
> > +	extrdi.	rTMP, rALT, 8, 16
> > +	stbu	rTMP, 1(rRTN)
> > +	beqlr
> > +	extrdi.	rTMP, rALT, 8, 24
> > +	stbu	rTMP, 1(rRTN)
> > +	beqlr
> > +	extrdi.	rTMP, rALT, 8, 32
> > +	stbu	rTMP, 1(rRTN)
> > +	beqlr
> > +	extrdi.	rTMP, rALT, 8, 40
> > +	stbu	rTMP, 1(rRTN)
> > +	beqlr
> > +	extrdi.	rTMP, rALT, 8, 48
> > +	stbu	rTMP, 1(rRTN)
> > +	beqlr
> > +	stbu	rALT, 1(rRTN)
> 
> I, like Ondrej, have trouble believing that 4 arithmetic insns + 1 unaligned
> load + 1 unaligned store is slower than this compare-branch ladder.
> 
> However good Power7's branch predictor is, I bet its out-of-order insn
> scheduler is better.  Issue the 6 insns, return from subroutine, surely.
> 
> You've got the location of the zero in rMASK from cmpb:
> 
>   cntlzd   rMASK, rMASK      // extract bit offset of nul byte
>   srdi     rMASK, rMASK, 3   // convert bit offset to byte offset
>   addi     rALT, rMASK, -7   // include the previous 7 bytes plus the nul
>   ldx      rTMP, rSRC, rALT  // perform one last unaligned copy
>   stdx     rTMP, rRTN, rALT
>   add      rRTN, rRTN, rMASK // adjust the return value
>   blr
> 

With unaligned load/stores we have to worry about crossing page
boundaries and perhaps a segfault. I don't see how you proposal
addresses that issue.

Also I would like the see the scrollpipe trace that backs up you
assertion.

The aggressive out-of-order nature of POWER and power7 specifically,
tends to give different results then our mental model based on our
experience with other processors.