[Bug string/26852] aarch64/strcmp has performance regression for some cases

[goldstein.w.n at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26852

--- Comment #11 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Wilco from comment #10)
> (In reply to Noah Goldstein from comment #9)
> > (In reply to yangyanchao6@huawei.com from comment #8)
> 
> > > - .p2align 4
> > > -
> > > L(loop_aligned):
> > > ldr data2, [src1, off2]
> > > ldr data1, [src1], 8
> > > 
> > > I removed the first alignment in strcmp and the 300% performance degradation
> > > disappeared.
> > 
> > Not an expert of the microarch but that sounds like a benchmark artifact.
> > Possibly check the decode path? If the change in alignment causes decode
> > to run / not-run out of the trace cache that would severely impact the
> > benchmark but not necessarily affect real-world performance (where
> > presumably strcmp is just run back-to-back-to-back in a loop).
> 
> As reported it does also occur in Dhrystone, so it's not due to calling
> strcmp in a tiny loop. It seems like an issue with the branch predictor not
> learning to predict certain loops. The question is whether the proposed
> workaround means all sizes now work without misprediction. Other string
> functions use small loops as well and compiled code will be affected too, so
> it's not clear to me there is an easy fix here.

Well whats causing the mispredictions? Clobber in the BHT?

By decode I was wondering if there was something like the
loop-stream-detector in aarch64. On x86 entering the LSD is
related to code alignment and can cause a spike in branch-misses
because its implemented s.t the only way to exit LSD decode 'mode'
is a branch-miss.

-- 
You are receiving this mail because:
You are on the CC list for the bug.