This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Obsolete powerpc*-*-*spe*


On Wed, Mar 15, 2017 at 11:12:53AM -0600, Sandra Loosemore wrote:
> >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

These two are SPE.

> -te500mc
> -te600

These two are "classic" PowerPC.

> -te200z0
> -te200z3
> -te200z4

These are VLE?  Do some of those also support PowerPC?

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

SPE *always* has to be statically configured for; you do not get support
for the SPE ABIs unless you specifically configure for it.

> I'm wondering whether the code in the rs6000 backend could be refactored 
> to better abstract and separate the complicated processor-dependent bits?

All the abstraction and indirection is part of what makes things so
complex :-(

Things that are complicated are for example the things that touch the
code in many places.  Like, vector types, register classes, output
modifiers, ABIs.  All of which are all over the machine description
and hooks.


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]