svn commit: r280279 - head/sys/sys

[John Baldwin]

On Sunday, March 22, 2015 11:32:51 AM Konstantin Belousov wrote:
> On Sun, Mar 22, 2015 at 09:41:53AM +1100, Bruce Evans wrote:
> > Always using new API would lose the micro-optimizations given by the runtime
> > decision for default CFLAGS (used by distributions for portability).  To
> > keep them, it seems best to keep the inline asm but replace
> > popcnt_pc_map_elem(elem) by __bitcount64(elem).  -mno-popcount can then
> > be used to work around slowness in the software (that is actually
> > hardware) case.
> 
> So anybody has to compile his own kernel to get popcnt optimization ?
> We do care about trivial things that improve time.

That is not what Bruce said.  He suggested using bitcount64() for the fallback
if the cpuid check fails.  He did not say to remove the runtime check to use
popcnt if it is available:

"Always using [bitcount64] would lose the micro-optimization... [to] keep
[it], it seems best to keep the inline asm but replace popcnt_pc_map_elem(elem)
by [bitcount64(elem)]."

> BTW, I have the following WIP change, which popcnt xorl is a piece of.
> It emulates the ifuncs with some preprocessing mess.  It is much better
> than runtime patching, and is a prerequisite to properly support more
> things, like SMAP.  I did not published it earlier, since I wanted to
> convert TLB flush code to this.

This looks fine to me.  It seems to be manually converting certain symbols
to use a dynamic lookup that must be explicitly resolved before first
use?  I agree that this seems cleaner than runtime patching.

-- 
John Baldwin