new baby in the multilib family

[Till Straumann]

I just realized that a new baby (8540) recently has joined the already big
powerpc multilib family (IMO w/o good reason).

I would like to propose to weed this jungle prior to branching 4.9.

In particular, I would like to propose the following:

a) clean up some general conflicts, e.g.,
   - RTEMS by default sets -meabi but MULTILIB_EXTRA_OPTS adds -mno-eabi
   - RTEMS allows the lwsync instruction even though this is IBM only 
and the use
     of this opcode is (AFAK) undocumented for motorola classic PPCs but 
crashes
     e.g., BookE and PSIM.
  - more stuff I don't remember out of my head right now...

b) have somebody explain why they think mcpu=XYZ other than mcpu=powerpc 
is necessary
    If no good reason is found after discussion, kill the unnecessary ones.

c) distill variants that really seem necessary. What comes to my mind is

         1) integer instruction set. AFAIK everything we currently use 
supports the
             classic PPC UISA. Thus my belief that we can make -mcpu=powerpc
             work.

         2) FPU variants. Currently, only variants for soft-float and 
classic FPU make
             sense. Once we have 64-bit GPR context save-restore a 
float-gprs variant
             could be added.

         3) ABI compatibility. Come up with a set of ABI variants that 
makes sense
            to support. What comes to my mind here:
                        hard and soft-float are NOT compatible
                        stack alignment of 16-bytes and 8-bytes could 
make sense

         4) Other
                        Altivec, SPE, ... hardware
                        use of short-data areas

RFC
-- Till