svn commit: r344118 - head/sys/i386/include
Konstantin Belousov
kostikbel at gmail.com
Fri Feb 15 14:04:19 UTC 2019
On Sat, Feb 16, 2019 at 12:27:16AM +1100, Bruce Evans wrote:
> On Fri, 15 Feb 2019, Konstantin Belousov wrote:
>
> > On Fri, Feb 15, 2019 at 07:16:04AM +0000, Alexey Dokuchaev wrote:
> >> On Thu, Feb 14, 2019 at 01:53:11PM +0000, Konstantin Belousov wrote:
> >>> New Revision: 344118
> >>> URL: https://svnweb.freebsd.org/changeset/base/344118
> >>>
> >>> Log:
> >>> Provide userspace versions of do_cpuid() and cpuid_count() on i386.
> >>>
> >>> Some older compilers, when generating PIC code, cannot handle inline
> >>> asm that clobbers %ebx (because %ebx is used as the GOT offset
> >>> register). Userspace versions avoid clobbering %ebx by saving it to
> >>> stack before executing the CPUID instruction.
> >>>
> >>> ...
> >>> +static __inline void
> >>> +do_cpuid(u_int ax, u_int *p)
> >>> +{
> >>> + __asm __volatile(
> >>> + "pushl\t%%ebx\n\t"
> >>> + "cpuid\n\t"
> >>> + "movl\t%%ebx,%1\n\t"
> >>> + "popl\t%%ebx"
> >>
> >> Is there a reason to prefer pushl+movl+popl instead of movl+xchgl?
> >>
> >> "movl %%ebx, %1\n\t"
> >> "cpuid\n\t"
> >> "xchgl %%ebx, %1"
> >
> > xchgl seems to be slower even in registers format (where no implicit
> > lock is used). If you can demonstrate that your fragment is better in
> > some microbenchmark, I can change it. But also note that its use is not
> > on the critical path.
>
> The should have the same speed on modern x86. xchgl %reg1,%reg2 is
> not slow, but it changes 2 visible registers and a needs somwhere to
> hold one of the registers while changing it, so on 14 year old AthlonXP
> where I know the times in cycles better, register xchgl was twice as slow
> as register move (2 cycles latency instead of 1, and throughput ==
> latency (?)). On 2015 Haswell, register movl in a loop is in parallel
> with the loop overhead (1 cycle), while xchgl and pushl/popl take 0.5
> cycles longer on average. Latency might be a problem for pushl/popl
> in critical paths. There aren't many of those.
I think on modern Intels xchgl is implemented by renaming. Still it is slower
than typically highly optimized push/pops.
That said, what is your preference ? My version or xchgl ?
My own preference is to leave it as is, since it is slightly slower,
and I do not want to spend several hours again, re-testing libc changes.
More information about the svn-src-all
mailing list