svn commit: r275468 - head/sys/dev/usb/controller

[John-Mark Gurney]

Dag-Erling Smrgrav wrote this message on Thu, Dec 04, 2014 at 19:28 +0100:
> John-Mark Gurney <jmg at funkthat.com> writes:
> > Did you see the comment about usig __builtin_ffs{,l,ll} instead? this
> > seems to be a better route...
> 
> No.  It's needlessly compiler-dependent.

I'm confused, in an earlier email you said:
Dag-Erling Smrgrav wrote this message on Thu, Dec 04, 2014 at 18:10 +0100:
> Dimitry Andric <dim at FreeBSD.org> writes:
> > Maybe it is easier to alias ffs() and friends to __builtin_ffs(),
> > since the compilers we support have these builtins already.
> 
> That should already be the case on platforms that support it.  There is
> absolutely no reason to hand-roll an ffs() equivalent.

So this says that you think it should be using the builtin, yet
when I suggested it, you say no?  Which is it?

Yes, it is compiler dependant, and yes, we are getting closer to
supporting external tool chains, but I doubt that the external tool
chain is going to be anything other than gcc or clang, which both
support all three...  If someone does want to add a compiler that
doesn't support it, it's easy enough for them to add an ifdef or
two and add the proper code...

Considering that we have hacks like:
#ifdef HAVE_INLINE_FFSL
                        cpu = CPU_FFS(&cpumask) - 1;
#else
                        while (cpu >= 0 && !CPU_ISSET(cpu, &cpumask))
                                cpu--;
#endif

in sched_ule.c, switching to always using builtin ffs and getting ride
of these hacks seems like the best choice...

If people feel that they need to implement ffs themselves, then we
clearly aren't doing our job of providing fast blocks to build upon...

> > So, how about changing libkern.h to define the various ones to the
> > built in, and dropping all the special versions?
> 
> This is (or should) be taken care of in cpufunc.h for platforms that
> support ffs / fls in hardware.

Considering that I'd trust the compiler writers to optimize their code
more than the people who port to a new platform, I disagree...  Rarely
do ports to a new platform back fill in support functions like these,
yet clearly, they are important, since mav thought it important enough
to hack sched_ule.c...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."