Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc

[Benjamin Herrenschmidt <benh at kernel dot crashing dot org>]

>   By the way, putting on my architecture hat, I noticed that
> the current allocation is all in-order from MSB down, going
> from computation mode (32/64) to ISA features (601 down to
> EFP-double) to system features (unified cache and no timebase),
> to chip microarch, with no breaks for future additions.  Would
> it be feasible to provide a break between NO_TB and POWER4
> (perhaps number the uarchs from LSB up?), so that if a new ISA
> extension is done, the bit encoding makes sense?  Something
> like "isel" seems worthy of addition, since that is
> UISA-visible and can have substantial performance impact.

I think it was a mistake to add the microarch like POWER4 in there. It
should have been a separate entity, possibly the ELF_PLATFORM string.
The change was done in a rush but not properly thought out (and that's
partially my fault too).

>   Also, is the 32-bit mode "true" 32-bit mode, and not the 970
> 32-bit mode?  That is, is a binary marked with PPC_FEATURE_32
> _guaranteed_ to run on a 601 without any program exceptions?  We
> have heard rumors that AIX and Apple, even in 32-bit mode, take
> advantage of the fact that 64-bit instructions can still be
> executed on a 970 in 32-bit mode.

They aren't supposed to do so unless they know for sure the proccessor
can (via the microarch for example). Also, doing so on linux is risky as
currently, signals don't save/restore the top 32 bits of registers for
32 bits processes.

> > 1) Negotiate with Paul Mackerras to get bits allocated in AT_HWCAP from 
> > the kernel.
> 
>   We will work on doing this.

As I wrote above, I think it's the wrong approach, we'll quickly run out
of bits if we continue putting the microarchitecture there, especially
with all the embedded ones lurking at the door.

We need, I think, to come up with a consistent naming scheme for
ELF_PLATFORM instead, possibly a doublet so we can separate the
processor architecture/family and the actual processor model if we feel
that is necessary.
 
> > 2) Verify that gcc has the -mcpu= support you need. If not you need to 
> > negotiate with David Edelsohn to get any -mcpu= support and __ARCH_ 
> > macro's you might need.
> 
>   Done, or in progress, for all of our production parts (e200,
> e300, e500, e600).
> 
> > 3) Provide detail analysis and justification of why the (widely used) 
> > processor/chip that you want to support is not well served by the current 
> > (default) implementation.
> 
>   We have seen some significant speedups on certain benchmarks
> (including SPEC) using some of the optimized libraries
> internally.  If deeper justification is required, we can work on that.
> 
> > 4) Provide optimized implementations of high use functions where needed.
> 
>   Some of this has already been done (libcfsl_e500,
> libmotovec), and more will be done in the future.

In addition, it might be worth using the vdso for some very processor
specific things, thus getting the benefit automatically without
requiring a different libc. I've been pondering putting implementations
of memcpy and spinlocks in there... food for thoughts at this point
though.

Ben.