Obsolete powerpc*-*-*spe*

David Edelsohn dje.gcc@gmail.com
Wed Mar 15 17:45:00 GMT 2017

On Wed, Mar 15, 2017 at 1:12 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> On 03/15/2017 08:26 AM, Segher Boessenkool wrote:
>> Since SPE and VLE only share the part of the rs6000 port that doesn't
>> change at all (except for a bug fix once or twice a year), and everything
>> else needs special cases all over the place, it seems to me it would be
>> best for everyone if we split the rs6000 port in two, one for SPE and VLE
>> and one for the rest.  Both ports could then be very significantly
>> simplified.
>> I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC,
>> please correct me if that is incorrect.  Also, is "normal" floating
>> point supported at all?
>> Do you (AdaCore and Mentor) think splitting the port is a good idea?
> I can't speak on behalf of Mentor, and Andrew is the target expert here, but
> we currently do ship all of SPE, VLE, and AltiVec multilibs in the same
> powerpc-eabi toolchain.  Specifically, the list is
> default (603e, e300c3, G2, etc)
> -te500v1
> -te500v2
> -te500mc
> -te600
> -te200z0
> -te200z3
> -te200z4
> plus some soft-float variants, etc.  Splitting these up into multiple
> toolchains that have to be statically configured for a particular
> architecture wouldn't be zero-cost either for us, other groups in Mentor
> that repackage our toolchains, or our end users.
> I'm wondering whether the code in the rs6000 backend could be refactored to
> better abstract and separate the complicated processor-dependent bits?


PowerPC, SPE and VLE are, to a large extent, different ISAs that share
some instruction mnemonics.  It requires overloading basic,
fundamental patterns in the GCC machine description.  Regardless of
way in which it is abstracted and refactored, it is going to be
complicated and difficult to maintain.

VLE is not going to be merged into the current rs6000 port of GCC.  If
AdaCore, Mentor and its customers want that functionality in FSF GCC,
they are going to have to take on the burden of a separate port.

I realize that splitting the port is not zero cost for Mentor, but
currently the vast majority of the maintenance cost is falling to the
IBM GCC Toolchain team.  That is not equitable and no longer
sustainable.  IBM can't shoulder the burden of lowering the
development expense for other vendors.

Thanks, David

More information about the Gcc mailing list