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

[Brian Grayson <Brian dot Grayson at freescale dot com>]

Steve Munroe wrote:
> Christoph Hellwig <hch@lst.de> wrote on 12/15/2005 06:36:01 AM:
> 
> > > We have made a deliberate decision not to identify older processor
> > > generations (POWER3, G4). They are no longer in production and/or are
> > > adequately covered by the current glibc implementation. They will continue
> > > to be supported by current base/default implementation (as defined by gcc
> > > options -mcpu=powerpc for 32-bit and -mcpu=powerpc64 for 64-bit).
> > 
> > That's not true.  G4, G3 and even G2-based microarchitectures are still
> > in production at motorola.  Not to mention things like the 8xx.
> 
> Did you miss the "or are adequately covered by the current glibc 
> implementation" part?
> 
> Note: I did not say they are not supported, I did say that I (personally) 
> was not going to do anything extra for them. I have my hands full keeping 
> on top of the current IBM products (along with all my other jobs).
> 
> But you should be supporting my efforts on this and the related --with-cpu 
> support. I have done all the heavy lifting to enable the general 
> mechanism. If you are supportive of this effort, then please say so.

  First of all, yes, we appreciate what you've done!

> If you are vitally interested in supporting G2, G3, G4 then you will need 
> to:

  Freescale (formerly Motorola SPS) is interested in supporting
all of these and more.  The e200, e300 (G2), e500, and e600
(G4) cores are all supported by gcc's -mcpu= options
(e.g., -mcpu=8540), so I think the main thing is to make sure
that the proper bits are allocated now.  e200 has a feature
that would require another HWCAP bit (compressed code, aka
"VLE"), for example.

  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.

  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.

> 1) Negotiate with Paul Mackerras to get bits allocated in AT_HWCAP from 
> the kernel.

  We will work on doing this.

> 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.

> Then we can work together to update dl-procinfo to support what you come 
> up with.

  Thanks for working on this.

  Brian Grayson
--
Brian Grayson, SysPerf (System Performance, Modeling, and Simulation)
Brian.Grayson@freescale.com
Somerset Design Center
Freescale Semiconductor
Austin, TX