Obsolete powerpc*-*-*spe*

Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

Hi all,

I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
the spe.h installed header file, all the __builtin_spe* intrinsics, the
-mfloat-gprs= command-line option, and the support for the SPE ABIs.

No one has properly tested these targets in a long time (the latest
testresults I could find are from July 2015, >1000 failures), and the
SPE support makes a lot of code much more complex.

Any objections to this obsoletion?  GCC 7 will then be the last release
with support for SPE (it will need --enable-obsolete to build these
targets), and we will delete the SPE support during GCC 8 development.


Segher

Re: Obsolete powerpc*-*-*spe*

[Jeff Law]

On 02/13/2017 08:07 PM, Segher Boessenkool wrote:
> Hi all,
>
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>
> No one has properly tested these targets in a long time (the latest
> testresults I could find are from July 2015, >1000 failures), and the
> SPE support makes a lot of code much more complex.
>
> Any objections to this obsoletion?  GCC 7 will then be the last release
> with support for SPE (it will need --enable-obsolete to build these
> targets), and we will delete the SPE support during GCC 8 development.
Works for me.  There's one old BZ I'm aware of that we would want to 
retarget at ARM/AARCH64 since it reproduces there too.  But that's easy 
enough to do.



jeff

Re: Obsolete powerpc*-*-*spe*

[Sebastian Huber]

Hello Segher,

On 14/02/17 04:07, Segher Boessenkool wrote:
> Hi all,
>
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>
> No one has properly tested these targets in a long time (the latest
> testresults I could find are from July 2015, >1000 failures), and the
> SPE support makes a lot of code much more complex.
>
> Any objections to this obsoletion?  GCC 7 will then be the last release
> with support for SPE (it will need --enable-obsolete to build these
> targets), and we will delete the SPE support during GCC 8 development.

the SPE unit is still used in the embedded PowerPC processors from 
Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not 
obsolete or even not recommended for new designs. These chips have a 
long product life-cycle.

Its a pity that Freescale/NXP/Qualcomm stopped to support GCC 
development and IBM is burdened to take care of this. I can understand 
your reasoning, however, its not true that there are no users of the SPE 
unit.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Obsolete powerpc*-*-*spe*

[David Edelsohn]

On Mon, Feb 13, 2017 at 10:07 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> Hi all,
>
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>
> No one has properly tested these targets in a long time (the latest
> testresults I could find are from July 2015, >1000 failures), and the
> SPE support makes a lot of code much more complex.
>
> Any objections to this obsoletion?  GCC 7 will then be the last release
> with support for SPE (it will need --enable-obsolete to build these
> targets), and we will delete the SPE support during GCC 8 development.

LGTM.

Thanks, David

Re: Obsolete powerpc*-*-*spe*

[David Brown]

On 14/02/17 12:55, Sebastian Huber wrote:
> Hello Segher,
> 
> On 14/02/17 04:07, Segher Boessenkool wrote:
>> Hi all,
>>
>> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
>> the spe.h installed header file, all the __builtin_spe* intrinsics, the
>> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>>
>> No one has properly tested these targets in a long time (the latest
>> testresults I could find are from July 2015, >1000 failures), and the
>> SPE support makes a lot of code much more complex.
>>
>> Any objections to this obsoletion?  GCC 7 will then be the last release
>> with support for SPE (it will need --enable-obsolete to build these
>> targets), and we will delete the SPE support during GCC 8 development.
> 
> the SPE unit is still used in the embedded PowerPC processors from
> Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not
> obsolete or even not recommended for new designs. These chips have a
> long product life-cycle.

It is also used in many PPC based microcontrollers, which are used in
the automotive industry and other places where you need highly reliable
and robust but powerful microcontrollers.  However, gcc support for
these has traditionally been poor - there is little support for the
variety of cores and configurations available from Freescale/NXP.  I
believe there is a chicken-and-egg situation here - few people use gcc
with these devices because there is poorer device support compared to
Freescale CodeWarrior or Green Hills, and there is little incentive for
gcc developers (such as the CodeSourcery or IBM PPC folks) to support
devices in gcc if no one uses that combination.

> 
> Its a pity that Freescale/NXP/Qualcomm stopped to support GCC
> development and IBM is burdened to take care of this. I can understand
> your reasoning, however, its not true that there are no users of the SPE
> unit.
> 

I think what would be needed would be for Freescale/NXP/Qualcomm to put
some money and effort in here, with the aim of making gcc their standard
compiler for these targets (as they have done for ARM, replacing the old
CodeWarrior compiler).

Failing that, it is of course better to have no SPE support than broken
SPE support, especially if it makes development harder for other devices.

Re: Obsolete powerpc*-*-*spe*

[Sebastian Huber]

On 14/02/17 15:09, David Brown wrote:
> On 14/02/17 12:55, Sebastian Huber wrote:
>> Hello Segher,
>>
>> On 14/02/17 04:07, Segher Boessenkool wrote:
>>> Hi all,
>>>
>>> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
>>> the spe.h installed header file, all the __builtin_spe* intrinsics, the
>>> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>>>
>>> No one has properly tested these targets in a long time (the latest
>>> testresults I could find are from July 2015, >1000 failures), and the
>>> SPE support makes a lot of code much more complex.
>>>
>>> Any objections to this obsoletion?  GCC 7 will then be the last release
>>> with support for SPE (it will need --enable-obsolete to build these
>>> targets), and we will delete the SPE support during GCC 8 development.
>> the SPE unit is still used in the embedded PowerPC processors from
>> Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not
>> obsolete or even not recommended for new designs. These chips have a
>> long product life-cycle.
> It is also used in many PPC based microcontrollers, which are used in
> the automotive industry and other places where you need highly reliable
> and robust but powerful microcontrollers.  However, gcc support for
> these has traditionally been poor - there is little support for the
> variety of cores and configurations available from Freescale/NXP.  I
> believe there is a chicken-and-egg situation here - few people use gcc
> with these devices because there is poorer device support compared to
> Freescale CodeWarrior or Green Hills, and there is little incentive for
> gcc developers (such as the CodeSourcery or IBM PPC folks) to support
> devices in gcc if no one uses that combination.

Yes, we use GCC also one these chips, however, due to the lack of VLE 
support the situation is even worse. Looks like support for the non-IBM 
PowerPC is dead in GCC. I can understand this pretty well.

With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no 
future in this area and they will move to ARM for the processor cores.

>
>> Its a pity that Freescale/NXP/Qualcomm stopped to support GCC
>> development and IBM is burdened to take care of this. I can understand
>> your reasoning, however, its not true that there are no users of the SPE
>> unit.
>>
> I think what would be needed would be for Freescale/NXP/Qualcomm to put
> some money and effort in here, with the aim of making gcc their standard
> compiler for these targets (as they have done for ARM, replacing the old
> CodeWarrior compiler).
>
> Failing that, it is of course better to have no SPE support than broken
> SPE support, especially if it makes development harder for other devices.
>

Yes, in case Qualcomm shows no interest to support their PowerPC stuff 
in GCC its quite understandable to remove the support for it eventually. 
IBM already did a great job in keeping it up and running for a long time.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

On Tue, Feb 14, 2017 at 03:26:09PM +0100, Sebastian Huber wrote:
> >>>I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> >>>the spe.h installed header file, all the __builtin_spe* intrinsics, the
> >>>-mfloat-gprs= command-line option, and the support for the SPE ABIs.
> >>>
> >>>No one has properly tested these targets in a long time (the latest
> >>>testresults I could find are from July 2015, >1000 failures), and the
> >>>SPE support makes a lot of code much more complex.
> >>>
> >>>Any objections to this obsoletion?  GCC 7 will then be the last release
> >>>with support for SPE (it will need --enable-obsolete to build these
> >>>targets), and we will delete the SPE support during GCC 8 development.
> >>the SPE unit is still used in the embedded PowerPC processors from
> >>Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not
> >>obsolete or even not recommended for new designs. These chips have a
> >>long product life-cycle.

Yes.  SPE is part of some e500 and some e200 CPUs I think (but only
some, in both cases).

> >It is also used in many PPC based microcontrollers, which are used in
> >the automotive industry and other places where you need highly reliable
> >and robust but powerful microcontrollers.  However, gcc support for
> >these has traditionally been poor - there is little support for the
> >variety of cores and configurations available from Freescale/NXP.  I
> >believe there is a chicken-and-egg situation here - few people use gcc
> >with these devices because there is poorer device support compared to
> >Freescale CodeWarrior or Green Hills, and there is little incentive for
> >gcc developers (such as the CodeSourcery or IBM PPC folks) to support
> >devices in gcc if no one uses that combination.
> 
> Yes, we use GCC also one these chips, however, due to the lack of VLE 
> support the situation is even worse. Looks like support for the non-IBM 
> PowerPC is dead in GCC. I can understand this pretty well.

It's not true though; we still support all those cores, just not the
VLE extension (we never have), and I propose GCC 7 will drop the SPE
extension as well -- not all other support we have for those cores.
They will have to use soft float, alas.

We also still support all non-IBM non-FSL cores.

> With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no 
> future in this area and they will move to ARM for the processor cores.

That is my understanding as well, yes.

> >>Its a pity that Freescale/NXP/Qualcomm stopped to support GCC
> >>development and IBM is burdened to take care of this. I can understand
> >>your reasoning, however, its not true that there are no users of the SPE
> >>unit.

(I never said there are no users, I'm well aware).  The burden is not
just IBM's, also all other GCC developers and users.

> >I think what would be needed would be for Freescale/NXP/Qualcomm to put
> >some money and effort in here, with the aim of making gcc their standard
> >compiler for these targets (as they have done for ARM, replacing the old
> >CodeWarrior compiler).
> >
> >Failing that, it is of course better to have no SPE support than broken
> >SPE support, especially if it makes development harder for other devices.
> 
> Yes, in case Qualcomm shows no interest to support their PowerPC stuff 
> in GCC its quite understandable to remove the support for it eventually. 
> IBM already did a great job in keeping it up and running for a long time.

That is the unfortunate reality.


Segher

Re: Obsolete powerpc*-*-*spe*

[Olivier Hainque]

Hi Segher,

> On Feb 14, 2017, at 04:07 , Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> Hi all,
> 
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
> 
> No one has properly tested these targets in a long time (the latest
> testresults I could find are from July 2015, >1000 failures), and the
> SPE support makes a lot of code much more complex.

> Any objections to this obsoletion?  GCC 7 will then be the last release
> with support for SPE (it will need --enable-obsolete to build these
> targets), and we will delete the SPE support during GCC 8 development.

While I understand you already know of existing users and I see the
background of your move, I believe it would be a real loss. Here are
a few datpoints from here:

We have quite a few active users of spe based ports, some big, on both
bare-metal and VxWorks configurations, including the recent VxWorks 7 series
that we're planning to contribute when stage1 reopens.

We are running a fair amount of tests nightly in-house, ACATS for Ada + various
batches of regression tests, so keep a constant eye on the state of these ports.

We are actually discussing running dejagnu testsuites as well, and we could
post test results as soon as we have them.

We have participated in the port maintenance in the past and are willing to
keep helping as much as we can. We don't have the manpower of chip makers for
new versions or extensions of course.

With Kind Regards,

Olivier

PowerPC -many

[Alan Modra]

Since we've been talking about obsoleting cpu support, how about
getting rid of -many in ASM_CPU_SPEC for gcc-8?

It's a horrible hack of mine to work around gcc -mcpu option handling
bugs which I think have been fixed, and to silence complaints from gas
about asm() written for multiple cpus (with presumably run-time
selection of which block of code gets executed depending on cpu).

It used to be just a linux hack, but I see David uses it in aix61.h
and aix71.h too?

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC -many

[Segher Boessenkool]

On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote:
> Since we've been talking about obsoleting cpu support, how about
> getting rid of -many in ASM_CPU_SPEC for gcc-8?

Sure, but that doesn't need advance warning to the users, does it?
Things worked before and stay working, nothing user-visible?


Segher

Re: PowerPC -many

[Alan Modra]

On Tue, Feb 14, 2017 at 06:38:40PM -0600, Segher Boessenkool wrote:
> On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote:
> > Since we've been talking about obsoleting cpu support, how about
> > getting rid of -many in ASM_CPU_SPEC for gcc-8?
> 
> Sure, but that doesn't need advance warning to the users, does it?

Probably not.

> Things worked before and stay working, nothing user-visible?

Except for bad user asm() that ought to be true.  Oh, and gcc bugs
like emitting power9 insns when -mcpu=power8.  You'd have some chance
that the assembler would complain rather than getting sigill at
run-time.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC -many

[Peter Bergner]

On 2/14/17 6:06 PM, Alan Modra wrote:
> Since we've been talking about obsoleting cpu support, how about
> getting rid of -many in ASM_CPU_SPEC for gcc-8?

+1

Peter

Re: PowerPC -many

[Jakub Jelinek]

On Wed, Feb 15, 2017 at 11:34:26AM +1030, Alan Modra wrote:
> On Tue, Feb 14, 2017 at 06:38:40PM -0600, Segher Boessenkool wrote:
> > On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote:
> > > Since we've been talking about obsoleting cpu support, how about
> > > getting rid of -many in ASM_CPU_SPEC for gcc-8?
> > 
> > Sure, but that doesn't need advance warning to the users, does it?
> 
> Probably not.
> 
> > Things worked before and stay working, nothing user-visible?
> 
> Except for bad user asm() that ought to be true.  Oh, and gcc bugs
> like emitting power9 insns when -mcpu=power8.  You'd have some chance
> that the assembler would complain rather than getting sigill at
> run-time.

What does gcc do when using target attribute, where one function is
power7, another power9, then another power8?

	Jakub

Re: PowerPC -many

[David Edelsohn]

On Wed, Feb 15, 2017 at 1:00 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Feb 15, 2017 at 11:34:26AM +1030, Alan Modra wrote:
>> On Tue, Feb 14, 2017 at 06:38:40PM -0600, Segher Boessenkool wrote:
>> > On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote:
>> > > Since we've been talking about obsoleting cpu support, how about
>> > > getting rid of -many in ASM_CPU_SPEC for gcc-8?
>> >
>> > Sure, but that doesn't need advance warning to the users, does it?
>>
>> Probably not.
>>
>> > Things worked before and stay working, nothing user-visible?
>>
>> Except for bad user asm() that ought to be true.  Oh, and gcc bugs
>> like emitting power9 insns when -mcpu=power8.  You'd have some chance
>> that the assembler would complain rather than getting sigill at
>> run-time.
>
> What does gcc do when using target attribute, where one function is
> power7, another power9, then another power8?

Ideally, GCC should be emitting pseudo-op directives to the assembler
to specify the architecture level, e.g.

.machine XXX

Both at the beginning of the assembly file and at any position in the
file where the architecture level changes.

There are some challenges to ensure that the compiler is aware of the
architecture level of the generated code.

Thanks, David

Re: Obsolete powerpc*-*-*spe*

[Patrick Oppenlander]

On 15/02/17 01:49, Segher Boessenkool wrote:
>>> It is also used in many PPC based microcontrollers, which are used in
>>> the automotive industry and other places where you need highly reliable
>>> and robust but powerful microcontrollers.  However, gcc support for
>>> these has traditionally been poor - there is little support for the
>>> variety of cores and configurations available from Freescale/NXP.  I
>>> believe there is a chicken-and-egg situation here - few people use gcc
>>> with these devices because there is poorer device support compared to
>>> Freescale CodeWarrior or Green Hills, and there is little incentive for
>>> gcc developers (such as the CodeSourcery or IBM PPC folks) to support
>>> devices in gcc if no one uses that combination.
>>
>> Yes, we use GCC also one these chips, however, due to the lack of VLE
>> support the situation is even worse. Looks like support for the non-IBM
>> PowerPC is dead in GCC. I can understand this pretty well.
>
> It's not true though; we still support all those cores, just not the
> VLE extension (we never have), and I propose GCC 7 will drop the SPE
> extension as well -- not all other support we have for those cores.
> They will have to use soft float, alas.

Will the SPFP APU still be supported?

Kind regards,

		Patrick

Re: Obsolete powerpc*-*-*spe*

[Patrick Oppenlander]

On 15/02/17 01:49, Segher Boessenkool wrote:

>> With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no
>> future in this area and they will move to ARM for the processor cores.
>
> That is my understanding as well, yes.

Our reps have suggested that the opposite may well be the case: It's 
Qualcomm buying into a large segment of the automotive MCU market.

I know of at least two issues they will face with an ARM takeover:
1. There's an enormous amount of legacy PowerPC code out there.
2. Currently only small (Cortex-M0/M3) cores are available in the 150C+ 
operating temperature ratings required for some automotive (engine bay 
or on engine) installations.

Of course these things can be overcome, but it will take time and effort.

		Patrick

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

On Thu, Feb 16, 2017 at 04:25:04PM +1100, Patrick Oppenlander wrote:
> >It's not true though; we still support all those cores, just not the
> >VLE extension (we never have), and I propose GCC 7 will drop the SPE
> >extension as well -- not all other support we have for those cores.
> >They will have to use soft float, alas.
> 
> Will the SPFP APU still be supported?

"SPE.Embedded Float Scalar Single" is part of SPE, so support for it
will be removed.  Sorry.


Segher

Re: Obsolete powerpc*-*-*spe*

[Sandra Loosemore]

On 02/13/2017 08:07 PM, Segher Boessenkool wrote:
> Hi all,
>
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>
> No one has properly tested these targets in a long time (the latest
> testresults I could find are from July 2015, >1000 failures), and the
> SPE support makes a lot of code much more complex.
>
> Any objections to this obsoletion?  GCC 7 will then be the last release
> with support for SPE (it will need --enable-obsolete to build these
> targets), and we will delete the SPE support during GCC 8 development.

Can I ask that we hold off a bit before making a decision on this?  I am 
pretty sure that some of Mentor's automotive customers use PowerPC 
processors with SPE support, but this is not my own area of expertise or 
responsibility and I need to chase down the right people in other 
groups, argue that we need to pick up the ball on maintenance if it's 
important to our customers, etc.

I don't think it's really appropriate to force this decision on the GCC 
community without giving other folks adequate notice that we can figure 
out what to do about it, anyway.  Maybe obsolete it if no maintainer can 
be found in 30 days, or something like that?

-Sandra

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:
> >I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> >the spe.h installed header file, all the __builtin_spe* intrinsics, the
> >-mfloat-gprs= command-line option, and the support for the SPE ABIs.
> >
> >No one has properly tested these targets in a long time (the latest
> >testresults I could find are from July 2015, >1000 failures), and the
> >SPE support makes a lot of code much more complex.
> >
> >Any objections to this obsoletion?  GCC 7 will then be the last release
> >with support for SPE (it will need --enable-obsolete to build these
> >targets), and we will delete the SPE support during GCC 8 development.
> 
> Can I ask that we hold off a bit before making a decision on this?

Of course, that is what we're doing in any case.

Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
we *can* remove it in GCC 8; we do not have to.  You have plenty of time
to find some way to keep SPE support in GCC.  The obsoletion notice _is_
the advance warning you're asking for.

The gcc-7/changes.html text I'll propose later says:


  <li><p>Support for a number of older systems and recently
  unmaintained or untested target ports of GCC has been declared
  obsolete in GCC 7.  Unless there is activity to revive them, the
  next release of GCC will have their sources permanently
  <strong>removed</strong>.</p>

  <p>The following ports for individual systems on
  particular architectures have been obsoleted:</p>

  <ul>
    <li>PowerPC SPE (powerpc*-*-*spe*) as announced
    <a href="https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html">
        here</a>.</li>
  </ul>
  </li>


Segher

Re: Obsolete powerpc*-*-*spe*

[Sandra Loosemore]

On 02/16/2017 03:19 PM, Segher Boessenkool wrote:
> On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:
>>> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
>>> the spe.h installed header file, all the __builtin_spe* intrinsics, the
>>> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>>>
>>> No one has properly tested these targets in a long time (the latest
>>> testresults I could find are from July 2015, >1000 failures), and the
>>> SPE support makes a lot of code much more complex.
>>>
>>> Any objections to this obsoletion?  GCC 7 will then be the last release
>>> with support for SPE (it will need --enable-obsolete to build these
>>> targets), and we will delete the SPE support during GCC 8 development.
>>
>> Can I ask that we hold off a bit before making a decision on this?
>
> Of course, that is what we're doing in any case.
>
> Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
> we *can* remove it in GCC 8; we do not have to.  You have plenty of time
> to find some way to keep SPE support in GCC.  The obsoletion notice _is_
> the advance warning you're asking for.
>
> The gcc-7/changes.html text I'll propose later says:
>
>
>    <li><p>Support for a number of older systems and recently
>    unmaintained or untested target ports of GCC has been declared
>    obsolete in GCC 7.  Unless there is activity to revive them, the
>    next release of GCC will have their sources permanently
>    <strong>removed</strong>.</p>
>
>    <p>The following ports for individual systems on
>    particular architectures have been obsoleted:</p>
>
>    <ul>
>      <li>PowerPC SPE (powerpc*-*-*spe*) as announced
>      <a href="https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html">
>          here</a>.</li>
>    </ul>
>    </li>

I understand that you're not going to remove the SPE support tomorrow. 
But that notice is going to scare users who depend on it, and I think 
it's not a good idea to scare users unnecessarily.  AFAIK GCC 7 is not 
going to be released tomorrow, either, so why not give folks a little 
more time to look into alternatives to announcing the support is being 
obsoleted?  IMO that should only be done when new maintainers have been 
solicited and nobody has come forward.

-Sandra

Re: Obsolete powerpc*-*-*spe*

[David Edelsohn]

On Thu, Feb 16, 2017 at 3:53 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> On 02/16/2017 03:19 PM, Segher Boessenkool wrote:
>>
>> On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:
>>>>
>>>> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
>>>> the spe.h installed header file, all the __builtin_spe* intrinsics, the
>>>> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>>>>
>>>> No one has properly tested these targets in a long time (the latest
>>>> testresults I could find are from July 2015, >1000 failures), and the
>>>> SPE support makes a lot of code much more complex.
>>>>
>>>> Any objections to this obsoletion?  GCC 7 will then be the last release
>>>> with support for SPE (it will need --enable-obsolete to build these
>>>> targets), and we will delete the SPE support during GCC 8 development.
>>>
>>>
>>> Can I ask that we hold off a bit before making a decision on this?
>>
>>
>> Of course, that is what we're doing in any case.
>>
>> Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
>> we *can* remove it in GCC 8; we do not have to.  You have plenty of time
>> to find some way to keep SPE support in GCC.  The obsoletion notice _is_
>> the advance warning you're asking for.
>>
>> The gcc-7/changes.html text I'll propose later says:
>>
>>
>>    <li><p>Support for a number of older systems and recently
>>    unmaintained or untested target ports of GCC has been declared
>>    obsolete in GCC 7.  Unless there is activity to revive them, the
>>    next release of GCC will have their sources permanently
>>    <strong>removed</strong>.</p>
>>
>>    <p>The following ports for individual systems on
>>    particular architectures have been obsoleted:</p>
>>
>>    <ul>
>>      <li>PowerPC SPE (powerpc*-*-*spe*) as announced
>>      <a href="https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html">
>>          here</a>.</li>
>>    </ul>
>>    </li>
>
>
> I understand that you're not going to remove the SPE support tomorrow. But
> that notice is going to scare users who depend on it, and I think it's not a
> good idea to scare users unnecessarily.  AFAIK GCC 7 is not going to be
> released tomorrow, either, so why not give folks a little more time to look
> into alternatives to announcing the support is being obsoleted?  IMO that
> should only be done when new maintainers have been solicited and nobody has
> come forward.

Sandra,

This is not a new issue.  The maintainer did not suddenly resign last
week.  There have been numerous efforts to reach out to the SPE
community for over a *decade*, cajoling them to step up with
maintenance for the port.  I am glad that this notice of obsolescence
has focused more attention on the long-standing problem.

Thanks, David

Re: Obsolete powerpc*-*-*spe*

[Richard Biener]

On Fri, Feb 17, 2017 at 1:10 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Thu, Feb 16, 2017 at 3:53 PM, Sandra Loosemore
> <sandra@codesourcery.com> wrote:
>> On 02/16/2017 03:19 PM, Segher Boessenkool wrote:
>>>
>>> On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:
>>>>>
>>>>> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
>>>>> the spe.h installed header file, all the __builtin_spe* intrinsics, the
>>>>> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
>>>>>
>>>>> No one has properly tested these targets in a long time (the latest
>>>>> testresults I could find are from July 2015, >1000 failures), and the
>>>>> SPE support makes a lot of code much more complex.
>>>>>
>>>>> Any objections to this obsoletion?  GCC 7 will then be the last release
>>>>> with support for SPE (it will need --enable-obsolete to build these
>>>>> targets), and we will delete the SPE support during GCC 8 development.
>>>>
>>>>
>>>> Can I ask that we hold off a bit before making a decision on this?
>>>
>>>
>>> Of course, that is what we're doing in any case.
>>>
>>> Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
>>> we *can* remove it in GCC 8; we do not have to.  You have plenty of time
>>> to find some way to keep SPE support in GCC.  The obsoletion notice _is_
>>> the advance warning you're asking for.
>>>
>>> The gcc-7/changes.html text I'll propose later says:
>>>
>>>
>>>    <li><p>Support for a number of older systems and recently
>>>    unmaintained or untested target ports of GCC has been declared
>>>    obsolete in GCC 7.  Unless there is activity to revive them, the
>>>    next release of GCC will have their sources permanently
>>>    <strong>removed</strong>.</p>
>>>
>>>    <p>The following ports for individual systems on
>>>    particular architectures have been obsoleted:</p>
>>>
>>>    <ul>
>>>      <li>PowerPC SPE (powerpc*-*-*spe*) as announced
>>>      <a href="https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html">
>>>          here</a>.</li>
>>>    </ul>
>>>    </li>
>>
>>
>> I understand that you're not going to remove the SPE support tomorrow. But
>> that notice is going to scare users who depend on it, and I think it's not a
>> good idea to scare users unnecessarily.  AFAIK GCC 7 is not going to be
>> released tomorrow, either, so why not give folks a little more time to look
>> into alternatives to announcing the support is being obsoleted?  IMO that
>> should only be done when new maintainers have been solicited and nobody has
>> come forward.
>
> Sandra,
>
> This is not a new issue.  The maintainer did not suddenly resign last
> week.  There have been numerous efforts to reach out to the SPE
> community for over a *decade*, cajoling them to step up with
> maintenance for the port.  I am glad that this notice of obsolescence
> has focused more attention on the long-standing problem.

+1

I'd like us to be more agressive in deprecating/removing of unmaintained
parts of GCC.  It's not only target/host support but also things like
unmaintained
language extensions (or frontends) as well as optimization passes.

Richard.

> Thanks, David

Re: Obsolete powerpc*-*-*spe*

[Janne Blomqvist]

On Fri, Feb 17, 2017 at 11:19 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> I'd like us to be more agressive in deprecating/removing of unmaintained
> parts of GCC.  It's not only target/host support but also things like
> unmaintained
> language extensions (or frontends) as well as optimization passes.

So... what about dropping i386 support? Steven Boscher suggested it 4
years ago following the Linux kernel dropping i386, but at that time
the discussion petered out without any firm conclusions either way.
See the thread starting at

https://gcc.gnu.org/ml/gcc/2012-12/msg00079.html

Or while we're at it, why not drop i486 too at the same time, unless
there are, well, users? That would additionally guarantee availability
of x87 (should we be happy or cry?), cpuid, cmpxchg8b, rdtsc.

-- 
Janne Blomqvist

Re: Obsolete powerpc*-*-*spe*

[Nathan Sidwell]

On 02/17/2017 04:19 AM, Richard Biener wrote:

> I'd like us to be more agressive in deprecating/removing of unmaintained
> parts of GCC.  It's not only target/host support but also things like
> unmaintained
> language extensions (or frontends) as well as optimization passes.

If you want a compiler that supports what a previous version supported, 
you know where to find it :)

nathan

-- 
Nathan Sidwell

Re: Obsolete powerpc*-*-*spe*

[Olivier Hainque]

Hi David,

> On Feb 17, 2017, at 01:10 , David Edelsohn <dje.gcc@gmail.com> wrote:
> 
> This is not a new issue.  The maintainer did not suddenly resign last
> week.  There have been numerous efforts to reach out to the SPE
> community for over a *decade*, cajoling them to step up with
> maintenance for the port.  I am glad that this notice of obsolescence
> has focused more attention on the long-standing problem.

Would there be a minimum level of commitment you'd like
to get to accept leaving the port in (if not this, at least
that ...) ?

Thanks,

Olivier

Re: Obsolete powerpc*-*-*spe*

[David Edelsohn]

On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque <hainque@adacore.com> wrote:
> Hi David,
>
>> On Feb 17, 2017, at 01:10 , David Edelsohn <dje.gcc@gmail.com> wrote:
>>
>> This is not a new issue.  The maintainer did not suddenly resign last
>> week.  There have been numerous efforts to reach out to the SPE
>> community for over a *decade*, cajoling them to step up with
>> maintenance for the port.  I am glad that this notice of obsolescence
>> has focused more attention on the long-standing problem.
>
> Would there be a minimum level of commitment you'd like
> to get to accept leaving the port in (if not this, at least
> that ...) ?

Hi, Olivier

There are three main areas that require attention:

1) Regular builds of the SPE configuration and regular GCC testsuite
runs that are reported to the gcc-testsuite mailing list.

2) Timely reports of any regressions.

3) An active GCC developer who is the point of contact for the SPE
port and submits patches for the port.

None of us within IBM are experts on the SPE port.  Someone from the
SPE community is needed to help triage issues, debug problems and test
patches that may affect the SPE port.

With evidence of pro-active involvement from an SPE developer, the
port does not have to be deprecated. The effort needs to be more that
activity at GCC release cycle boundaries or an accelerated deprecation
process will be proposed.

Thanks, David

Re: Obsolete powerpc*-*-*spe*

[Olivier Hainque]

> On 21 Feb 2017, at 17:14, David Edelsohn <dje.gcc@gmail.com> wrote:
> 
> Hi, Olivier
> 
> There are three main areas that require attention:
> 
> 1) Regular builds of the SPE configuration and regular GCC testsuite
> runs that are reported to the gcc-testsuite mailing list.
> 
> 2) Timely reports of any regressions.
> 
> 3) An active GCC developer who is the point of contact for the SPE
> port and submits patches for the port.
> 
> None of us within IBM are experts on the SPE port.  Someone from the
> SPE community is needed to help triage issues, debug problems and test
> patches that may affect the SPE port.
> 
> With evidence of pro-active involvement from an SPE developer, the
> port does not have to be deprecated. The effort needs to be more that
> activity at GCC release cycle boundaries or an accelerated deprecation
> process will be proposed.

Sure. Thanks David,

Olivier

Re: Obsolete powerpc*-*-*spe*

[Arnaud Charlet]

> > There are three main areas that require attention:
> > 
> > 1) Regular builds of the SPE configuration and regular GCC testsuite
> > runs that are reported to the gcc-testsuite mailing list.
> > 
> > 2) Timely reports of any regressions.
> > 
> > 3) An active GCC developer who is the point of contact for the SPE
> > port and submits patches for the port.
> > 
> > None of us within IBM are experts on the SPE port.  Someone from the
> > SPE community is needed to help triage issues, debug problems and test
> > patches that may affect the SPE port.
> > 
> > With evidence of pro-active involvement from an SPE developer, the
> > port does not have to be deprecated. The effort needs to be more that
> > activity at GCC release cycle boundaries or an accelerated deprecation
> > process will be proposed.

Thanks for your feedback David.

Note that AdaCore has a direct interest in keeping this port live for the
time being hence our questions. We are discussing internally whether some
of us at AdaCore could step up to continue maintaining this port, so please
stay tuned and involve us before making any decision :-)

Arno

Re: Obsolete powerpc*-*-*spe*

[Andrew Jenner]

On 21/02/2017 16:14, David Edelsohn wrote:
> On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque <hainque@adacore.com> wrote:
>>> On Feb 17, 2017, at 01:10 , David Edelsohn <dje.gcc@gmail.com> wrote:
>>>
>>> This is not a new issue.  The maintainer did not suddenly resign last
>>> week.  There have been numerous efforts to reach out to the SPE
>>> community for over a *decade*, cajoling them to step up with
>>> maintenance for the port.  I am glad that this notice of obsolescence
>>> has focused more attention on the long-standing problem.
>>
>> Would there be a minimum level of commitment you'd like
>> to get to accept leaving the port in (if not this, at least
>> that ...) ?
>
> [...]
>
> There are three main areas that require attention:
>
> 1) Regular builds of the SPE configuration and regular GCC testsuite
> runs that are reported to the gcc-testsuite mailing list.
>
> 2) Timely reports of any regressions.
>
> 3) An active GCC developer who is the point of contact for the SPE
> port and submits patches for the port.
>
> None of us within IBM are experts on the SPE port.  Someone from the
> SPE community is needed to help triage issues, debug problems and test
> patches that may affect the SPE port.
>
> With evidence of pro-active involvement from an SPE developer, the
> port does not have to be deprecated. The effort needs to be more that
> activity at GCC release cycle boundaries or an accelerated deprecation
> process will be proposed.

I volunteer to be the point of contact for the SPE port.

Over here at CodeSourcery/Mentor Embedded, we have a strong interest in 
SPE *not* being deprecated (we actively ship toolchain products with SPE 
multilibs, and have customers for which these are important). We are 
therefore volunteering resources (specifically, me) to maintain SPE 
upstream as well.

I am in the process of developing some patches to add VLE support 
upstream (and expect to be maintainer of those once they are committed) 
so it would be a good fit for me to be the SPE maintainer as well.

We have been regularly running tests on the SPE multilibs (on our 
internal branches) and they are in better shape than the test results 
Segher found from 2015. We may have some (not yet upstreamed) patches 
that improve the test results - I will be tracking these down and 
upstreaming them ASAP. I will be expanding our regular build and test 
runs to cover trunk as well, and will send test results to gcc-testsuite 
and report regressions.

If there is no objection, I will submit patches tomorrow to un-obsolete 
SPE and add myself to the appropriate section of the MAINTAINERS file. 
The other changes will come once stage 1 opens.

Thanks,

Andrew

Re: Obsolete powerpc*-*-*spe*

[Olivier Hainque]

Hello Andrew,

> On Mar 13, 2017, at 19:01 , Andrew Jenner <andrew@codesourcery.com> wrote:
> 
> I volunteer to be the point of contact for the SPE port.
> 
> Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE *not* being deprecated (we actively ship toolchain products with SPE multilibs, and have customers for which these are important). We are therefore volunteering resources (specifically, me) to maintain SPE upstream as well.
> 
> I am in the process of developing some patches to add VLE support upstream (and expect to be maintainer of those once they are committed) so it would be a good fit for me to be the SPE maintainer as well.
> 
> We have been regularly running tests on the SPE multilibs (on our internal branches) and they are in better shape than the test results Segher found from 2015. We may have some (not yet upstreamed) patches that improve the test results - I will be tracking these down and upstreaming them ASAP. I will be expanding our regular build and test runs to cover trunk as well, and will send test results to gcc-testsuite and report regressions.
> 
> If there is no objection, I will submit patches tomorrow to un-obsolete SPE and add myself to the appropriate section of the MAINTAINERS file. The other changes will come once stage 1 opens.

Thanks for volunteering!

As mentioned upthread, we (AdaCore) also have a significant user base,
so a strong interest in the port remaining alive and we'll be happy to
keep submitting patches we might have.

The perspective of seeing VLE support come in is great news :)

Best Wishes,


Olivier

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

Hi all,

On Wed, Mar 15, 2017 at 11:01:31AM +0100, Olivier Hainque wrote:
> > On Mar 13, 2017, at 19:01 , Andrew Jenner <andrew@codesourcery.com> wrote:
> > I volunteer to be the point of contact for the SPE port.
> > 
> > Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE *not* being deprecated (we actively ship toolchain products with SPE multilibs, and have customers for which these are important). We are therefore volunteering resources (specifically, me) to maintain SPE upstream as well.
> > 
> > I am in the process of developing some patches to add VLE support upstream (and expect to be maintainer of those once they are committed) so it would be a good fit for me to be the SPE maintainer as well.
> > 
> > We have been regularly running tests on the SPE multilibs (on our internal branches) and they are in better shape than the test results Segher found from 2015. We may have some (not yet upstreamed) patches that improve the test results - I will be tracking these down and upstreaming them ASAP. I will be expanding our regular build and test runs to cover trunk as well, and will send test results to gcc-testsuite and report regressions.
> > 
> > If there is no objection, I will submit patches tomorrow to un-obsolete SPE and add myself to the appropriate section of the MAINTAINERS file. The other changes will come once stage 1 opens.
> 
> Thanks for volunteering!
> 
> As mentioned upthread, we (AdaCore) also have a significant user base,
> so a strong interest in the port remaining alive and we'll be happy to
> keep submitting patches we might have.
> 
> The perspective of seeing VLE support come in is great news :)

It is good to hear there are some parties who promise to do some actual
work for this :-)

I do not think VLE can get in, not in its current shape at least.  VLE
is very unlike PowerPC in many ways so it comes at a very big cost to
the port (maintenance and otherwise -- maintenance is what I care about
most).

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?


Segher

Re: Obsolete powerpc*-*-*spe*

[Olivier Hainque]

> On Mar 15, 2017, at 15:26 , Segher Boessenkool <segher@kernel.crashing.org> wrote:

> I do not think VLE can get in, not in its current shape at least.  VLE
> is very unlike PowerPC in many ways so it comes at a very big cost to
> the port (maintenance and otherwise -- maintenance is what I care about
> most).
> 
> 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?

That's actually an option we considered.

We haven't gone very far in studying what this would entail and were still
unclear on how much of a clean separation we could get without risking the
introduction of (too much) instability.

It seemed like avoiding code duplication (that would otherwise be a maintenance
issue) might require refactoring in sensitive areas, e.g. prologue/epilogue
expansion, but the perspective of getting two variants simpler to grasp on top
of common code definitely sounds attractive and worth some effort.

Olivier

Re: Obsolete powerpc*-*-*spe*

[Sandra Loosemore]

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?

-Sandra

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

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

Re: Obsolete powerpc*-*-*spe*

[David Edelsohn]

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?

Sandra,

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

Re: Obsolete powerpc*-*-*spe*

[Andrew Jenner]

On 15/03/2017 14:26, Segher Boessenkool wrote:
> I do not think VLE can get in, not in its current shape at least.

That's unfortunate. Disregarding the SPE splitting plan for a moment, 
what do you think would need to be done to get it into shape? I had 
thought we were almost there with the patches that I sent to you and 
David off-list last year.

 > VLE
> is very unlike PowerPC in many ways so it comes at a very big cost to
> the port (maintenance and otherwise -- maintenance is what I care about
> most).

I completely understand.

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

My understanding is that SPE is only present in the e500v1, e500v2 and 
e200z[3-7] cores, all of which are 32-bit only and do not have classic 
floating-point units. SPE and Altivec cannot coexist as they have some 
overlapping instruction encodings. The successor to e500v2 (e500mc) 
reinstated classic floating-point and got rid of SPE.

> Do you (AdaCore and Mentor) think splitting the port is a good idea?

It wouldn't have been my preference, but I can understand the appeal of 
that plan for you. I'm surprised that the amount of shared code between 
SPE and PowerPC is as little as you say, but you have much more 
experience with the PowerPC port than I do, so I'll defer to your 
expertise on that matter.

Are you proposing to take on the task of actually splitting it yourself? 
If so, that would make me a lot happier about it.


 >> -te200z0
 >> -te200z3
 >> -te200z4
 >
 > These are VLE?

Yes.

 > Do some of those also support PowerPC?

All the e200 cores apart from e200z0 can execute 32-bit instructions as 
well as VLE, though we'll always generate VLE code when targetting them 
(otherwise they're fairly standard).

Andrew

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

Hi Andrew,

On Wed, Mar 15, 2017 at 09:43:20PM +0000, Andrew Jenner wrote:
> On 15/03/2017 14:26, Segher Boessenkool wrote:
> >I do not think VLE can get in, not in its current shape at least.
> 
> That's unfortunate. Disregarding the SPE splitting plan for a moment, 
> what do you think would need to be done to get it into shape? I had 
> thought we were almost there with the patches that I sent to you and 
> David off-list last year.
> 
> > VLE
> >is very unlike PowerPC in many ways so it comes at a very big cost to
> >the port (maintenance and otherwise -- maintenance is what I care about
> >most).
> 
> I completely understand.

That answers your previous question, too.

> >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?
> 
> My understanding is that SPE is only present in the e500v1, e500v2 and 
> e200z[3-7] cores, all of which are 32-bit only and do not have classic 
> floating-point units. SPE and Altivec cannot coexist as they have some 
> overlapping instruction encodings. The successor to e500v2 (e500mc) 
> reinstated classic floating-point and got rid of SPE.

e500mc (like e5500, e6500) are just PowerPC (and they use the usual ABIs),
so those should stay on the "rs6000 side".

> >Do you (AdaCore and Mentor) think splitting the port is a good idea?
> 
> It wouldn't have been my preference, but I can understand the appeal of 
> that plan for you. I'm surprised that the amount of shared code between 
> SPE and PowerPC is as little as you say, but you have much more 
> experience with the PowerPC port than I do, so I'll defer to your 
> expertise on that matter.
> 
> Are you proposing to take on the task of actually splitting it yourself? 
> If so, that would make me a lot happier about it.

Yes, I can do the mechanics.  But I cannot do most of the testing.  And
this does not include any of the huge simplifications that can be done
after the split: both ports will be very close to what we have now,
immediately after the split.

> >> -te200z0
> >> -te200z3
> >> -te200z4
> >
> > These are VLE?
> 
> Yes.
> 
> > Do some of those also support PowerPC?
> 
> All the e200 cores apart from e200z0 can execute 32-bit instructions as 
> well as VLE, though we'll always generate VLE code when targetting them 
> (otherwise they're fairly standard).

Do any e200 support SPE, or classic FP?


Segher

Re: Obsolete powerpc*-*-*spe*

[Andrew Jenner]

Hi Segher,

On 16/03/2017 19:24, Segher Boessenkool wrote:
> e500mc (like e5500, e6500) are just PowerPC (and they use the usual ABIs),
> so those should stay on the "rs6000 side".

Agreed.

>> Are you proposing to take on the task of actually splitting it yourself?
>> If so, that would make me a lot happier about it.
>
> Yes, I can do the mechanics.  But I cannot do most of the testing.

That's fine (and what I expected).

> And
> this does not include any of the huge simplifications that can be done
> after the split: both ports will be very close to what we have now,
> immediately after the split.

I'd have thought that the simplifications would be the bulk of the 
work... The simplification of the classic PowerPC port would be the 
removal of the SPE code. What would be removed from the SPE port - 
anything other than Altivec and 64-bit?

>> All the e200 cores apart from e200z0 can execute 32-bit instructions as
>> well as VLE, though we'll always generate VLE code when targetting them
>> (otherwise they're fairly standard).
>
> Do any e200 support SPE, or classic FP?

The e200z3 upwards have SPE units. None of them have classic FP. So it 
would make most sense for the e200/VLE support to be part of the SPE 
backend rather than the classic PowerPC backend.

Andrew

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

On Thu, Mar 16, 2017 at 08:38:37PM +0000, Andrew Jenner wrote:
> >>Are you proposing to take on the task of actually splitting it yourself?
> >>If so, that would make me a lot happier about it.
> >
> >Yes, I can do the mechanics.  But I cannot do most of the testing.
> 
> That's fine (and what I expected).
> 
> >And
> >this does not include any of the huge simplifications that can be done
> >after the split: both ports will be very close to what we have now,
> >immediately after the split.
> 
> I'd have thought that the simplifications would be the bulk of the 
> work...

The simplifications are not necessary to make things work.  They can
all be done piecemeal, and later (we should do the split during early
stage1 if possible).

I cannot promise you much of IBM's time (or my own abundant spare time),
but we will of course be available for advice and questions etc.

It is not like removing 20k or 30k lines is as much work as writing
them, of course ;-)

> The simplification of the classic PowerPC port would be the 
> removal of the SPE code. What would be removed from the SPE port - 
> anything other than Altivec and 64-bit?

Don't forget the other vector stuff, VSX.  It is not small or simple.

> >>All the e200 cores apart from e200z0 can execute 32-bit instructions as
> >>well as VLE, though we'll always generate VLE code when targetting them
> >>(otherwise they're fairly standard).
> >
> >Do any e200 support SPE, or classic FP?
> 
> The e200z3 upwards have SPE units. None of them have classic FP. So it 
> would make most sense for the e200/VLE support to be part of the SPE 
> backend rather than the classic PowerPC backend.

Great to hear!  And all e300 are purely "classic"?


Segher

Re: Obsolete powerpc*-*-*spe*

[Andrew Jenner]

On 16/03/2017 21:11, Segher Boessenkool wrote:
>> The e200z3 upwards have SPE units. None of them have classic FP. So it
>> would make most sense for the e200/VLE support to be part of the SPE
>> backend rather than the classic PowerPC backend.
>
> Great to hear!  And all e300 are purely "classic"?

That's one I'm less familiar with (as we don't deliver a multilib for 
it), but yes - my understanding is that this is classic core.

Andrew

Re: Obsolete powerpc*-*-*spe*

[Sebastian Huber]

On 16/03/17 22:16, Andrew Jenner wrote:
> On 16/03/2017 21:11, Segher Boessenkool wrote:
>>> The e200z3 upwards have SPE units. None of them have classic FP. So it
>>> would make most sense for the e200/VLE support to be part of the SPE
>>> backend rather than the classic PowerPC backend.
>>
>> Great to hear!  And all e300 are purely "classic"?
>
> That's one I'm less familiar with (as we don't deliver a multilib for 
> it), but yes - my understanding is that this is classic core.

Yes, the e300 is a classic PowerPC. It is a successor of the 603e. The 
name e300 is confusing. It is quite unrelated to the e200 and e500 cores.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Obsolete powerpc*-*-*spe*

[Maciej W. Rozycki]

On Wed, 15 Mar 2017, Andrew Jenner wrote:

> > 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?
> 
> My understanding is that SPE is only present in the e500v1, e500v2 and
> e200z[3-7] cores, all of which are 32-bit only and do not have classic
> floating-point units. SPE and Altivec cannot coexist as they have some
> overlapping instruction encodings. The successor to e500v2 (e500mc) reinstated
> classic floating-point and got rid of SPE.

 The VLE ISA does support 64-bit implementations, using the same binary 
instruction encodings for 64-bit operations as the regular Power ISA (e.g. 
ldx, ldux, etc.), though I have no idea if such hardware actually exists 
or has been planned.

> > Do some of those also support PowerPC?
> 
> All the e200 cores apart from e200z0 can execute 32-bit instructions as well
> as VLE, though we'll always generate VLE code when targetting them (otherwise
> they're fairly standard).

 Many regular Power ISA binary instruction encodings are also supported in 
the VLE mode, especially where a replacement VLE encoding has not been 
invented.  These include all 3-argument register ALU operations and many 
more (e.g. stbx, stbux, etc.).  The VLE PEM lists over 100 regular Power 
instruction encodings retained (not counting optional 64-bit operations).

 So it's not that the VLE instruction set only shares mnemonics with the 
regular Power instruction set.  In fact the opposite is the case: all the 
mnemonics that have been retained assemble to the same binary machine 
instructions, then some mnemonics (and their corresponding binary 
encodings) have been removed and some added (these are prefixed with `e_' 
for 32-bit binary encodings and `se_' for 16-bit ones).

 This intersection of the instruction sets was one motivation for keeping 
the ports together.

 FWIW,

  Maciej

PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Andrew Jenner]

On 13/03/2017 18:01, Andrew Jenner wrote:
> I volunteer to be the point of contact for the SPE port.
>
> Over here at CodeSourcery/Mentor Embedded, we have a strong interest in
> SPE *not* being deprecated (we actively ship toolchain products with SPE
> multilibs, and have customers for which these are important). We are
> therefore volunteering resources (specifically, me) to maintain SPE
> upstream as well.

Ping.

My understanding is that I need to be appointed by the steering 
committee to become a maintainer, but I have not yet heard anything from 
them.

Either way, I will work on cleaning up the SPE test results and getting 
some patches sent upstream to make sure this part of the port is in good 
shape.

Thanks,

Andrew

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Segher Boessenkool]

Hi Andrew,

On Wed, Apr 26, 2017 at 10:18:55AM +0100, Andrew Jenner wrote:
> On 13/03/2017 18:01, Andrew Jenner wrote:
> >I volunteer to be the point of contact for the SPE port.
> >
> >Over here at CodeSourcery/Mentor Embedded, we have a strong interest in
> >SPE *not* being deprecated (we actively ship toolchain products with SPE
> >multilibs, and have customers for which these are important). We are
> >therefore volunteering resources (specifically, me) to maintain SPE
> >upstream as well.
> 
> Ping.
> 
> My understanding is that I need to be appointed by the steering 
> committee to become a maintainer, but I have not yet heard anything from 
> them.
> 
> Either way, I will work on cleaning up the SPE test results and getting 
> some patches sent upstream to make sure this part of the port is in good 
> shape.

Here's the sequence of things that should happen:

1) Test results are posted to gcc-testresults@, ideally regularly.
Without test results no one can know if they break things.

2) The port has to be created.  I volunteered to do that.  This can
start soon after the GCC 7 release.  It will be hard to do without
having test results.

We also still have to agree on the target triples for the new port.
If you have any thoughts on this, I'd love to hear them.

3) The port has to be accepted by the steering committee, and you
appointed the maintainer.  This should be just a formality after 1)
and 2).


Segher

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Jeff Law]

On 04/28/2017 05:15 PM, Segher Boessenkool wrote:
> Hi Andrew,
> 
> On Wed, Apr 26, 2017 at 10:18:55AM +0100, Andrew Jenner wrote:
>> On 13/03/2017 18:01, Andrew Jenner wrote:
>>> I volunteer to be the point of contact for the SPE port.
>>>
>>> Over here at CodeSourcery/Mentor Embedded, we have a strong interest in
>>> SPE *not* being deprecated (we actively ship toolchain products with SPE
>>> multilibs, and have customers for which these are important). We are
>>> therefore volunteering resources (specifically, me) to maintain SPE
>>> upstream as well.
>>
>> Ping.
>>
>> My understanding is that I need to be appointed by the steering
>> committee to become a maintainer, but I have not yet heard anything from
>> them.
>>
>> Either way, I will work on cleaning up the SPE test results and getting
>> some patches sent upstream to make sure this part of the port is in good
>> shape.
> 
> Here's the sequence of things that should happen:
> 
> 1) Test results are posted to gcc-testresults@, ideally regularly.
> Without test results no one can know if they break things.
> 
> 2) The port has to be created.  I volunteered to do that.  This can
> start soon after the GCC 7 release.  It will be hard to do without
> having test results.
> 
> We also still have to agree on the target triples for the new port.
> If you have any thoughts on this, I'd love to hear them.
> 
> 3) The port has to be accepted by the steering committee, and you
> appointed the maintainer.  This should be just a formality after 1)
> and 2).
Given that it's being carved out of the existing PPC port, I think this 
will all be formality.

Andrew -- the ia16 work isn't forgotten either.  I'm just starting to 
dig into the gcc-8 stuff and the ia16 port is in that list.
jeff

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Joseph Myers]

On Sat, 29 Apr 2017, Segher Boessenkool wrote:

> We also still have to agree on the target triples for the new port.
> If you have any thoughts on this, I'd love to hear them.

It seems fairly obvious that the powerpc-*-eabispe* and 
powerpc*-*-linux*spe* triples should continue to work while being mapped 
to the new CPU port.  It's less obvious what triples should be used for 
SPE versions of other SPE-supporting configurations such as 
powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*.

Some testcases will be applicable to both ports, some to only one.

Maintainers of each port should of course watch the other port for changes 
that should be carried across, even if we believe, as has been stated in 
this discussion, that the parts of the code that would be present in both 
ports are stable and very rarely change.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Segher Boessenkool]

On Mon, May 01, 2017 at 10:48:05AM +0000, Joseph Myers wrote:
> On Sat, 29 Apr 2017, Segher Boessenkool wrote:
> 
> > We also still have to agree on the target triples for the new port.
> > If you have any thoughts on this, I'd love to hear them.
> 
> It seems fairly obvious that the powerpc-*-eabispe* and 
> powerpc*-*-linux*spe* triples should continue to work while being mapped 
> to the new CPU port.  It's less obvious what triples should be used for 
> SPE versions of other SPE-supporting configurations such as 
> powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*.

My current patches have powerpc*-*-*spe* for the powerpcspe port.
Maybe it should also allow powerpcspe-*-*?  If people are willing
to change the target triple they use.

> Some testcases will be applicable to both ports, some to only one.

Yeah; but we can sort that out later, no change is needed as long as
the new port is essentially a copy of rs6000 :-)

> Maintainers of each port should of course watch the other port for changes 
> that should be carried across, even if we believe, as has been stated in 
> this discussion, that the parts of the code that would be present in both 
> ports are stable and very rarely change.

Right.


Segher

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Joseph Myers]

On Mon, 1 May 2017, Segher Boessenkool wrote:

> My current patches have powerpc*-*-*spe* for the powerpcspe port.
> Maybe it should also allow powerpcspe-*-*?  If people are willing
> to change the target triple they use.

In that case, either config.sub or config.gcc could handle the mapping.

> > Some testcases will be applicable to both ports, some to only one.
> 
> Yeah; but we can sort that out later, no change is needed as long as
> the new port is essentially a copy of rs6000 :-)

Presumably the SPE port maintainers will want to clean up the SPE port 
soon so it's not simply a copy of rs6000 (removing all the options, ABI 
variants etc. not applicable to SPE-supporting processors).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Segher Boessenkool]

On Mon, May 01, 2017 at 11:30:59AM +0000, Joseph Myers wrote:
> On Mon, 1 May 2017, Segher Boessenkool wrote:
> 
> > My current patches have powerpc*-*-*spe* for the powerpcspe port.
> > Maybe it should also allow powerpcspe-*-*?  If people are willing
> > to change the target triple they use.
> 
> In that case, either config.sub or config.gcc could handle the mapping.

For powerpc*-*-*spe* in config.gcc, for powerpcspe-*-* in config.sub,
yes.  Which is also why the latter is a larger change: all other
packages would see it as a separate arch, too; which might make it a
non-starter.

> > > Some testcases will be applicable to both ports, some to only one.
> > 
> > Yeah; but we can sort that out later, no change is needed as long as
> > the new port is essentially a copy of rs6000 :-)
> 
> Presumably the SPE port maintainers will want to clean up the SPE port 
> soon so it's not simply a copy of rs6000 (removing all the options, ABI 
> variants etc. not applicable to SPE-supporting processors).

Yes, and vice-versa.  Of course the powerpcspe port can remove a lot
more (VMX, VSX, 64-bit!)

But these are the easy parts :-)


Segher

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Joel Sherrill]

On 5/1/2017 5:48 AM, Joseph Myers wrote:
> On Sat, 29 Apr 2017, Segher Boessenkool wrote:
>
>> We also still have to agree on the target triples for the new port.
>> If you have any thoughts on this, I'd love to hear them.
>
> It seems fairly obvious that the powerpc-*-eabispe* and
> powerpc*-*-linux*spe* triples should continue to work while being mapped
> to the new CPU port.  It's less obvious what triples should be used for
> SPE versions of other SPE-supporting configurations such as
> powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*.

powerpc-*-rtemsspe* would be OK.

powerpc-*-eabisimspe* is pretty ugly though.

It is obvious but if powerpc-*-XXXspe* is the pattern, then the
spe cases need to be above in all configure switches. I hate to
mention it but a fair number of odd RTEMS issues turn out to be
from inadvertent side-effects when cleaning up configure switches.
  
> Some testcases will be applicable to both ports, some to only one.
>
> Maintainers of each port should of course watch the other port for changes
> that should be carried across, even if we believe, as has been stated in
> this discussion, that the parts of the code that would be present in both
> ports are stable and very rarely change.
>

--joel

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Joel Sherrill]

On 5/1/2017 10:47 AM, Joel Sherrill wrote:
>
>
> On 5/1/2017 5:48 AM, Joseph Myers wrote:
>> On Sat, 29 Apr 2017, Segher Boessenkool wrote:
>>
>>> We also still have to agree on the target triples for the new port.
>>> If you have any thoughts on this, I'd love to hear them.
>>
>> It seems fairly obvious that the powerpc-*-eabispe* and
>> powerpc*-*-linux*spe* triples should continue to work while being mapped
>> to the new CPU port.  It's less obvious what triples should be used for
>> SPE versions of other SPE-supporting configurations such as
>> powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*.
>
> powerpc-*-rtemsspe* would be OK.
>
> powerpc-*-eabisimspe* is pretty ugly though.


After I sent this, I saw in another response that powerpcspe*-*-*
was proposed. Is that clearer?

For rtems, we already used versioned triplets. powerpc-rtems4.12
for example. owerpcspe-rtems4.12 seems more correct because spe
is part of the CPU architecture.

Otherwise, would it be powerpc-rtems4.12spe or powerpc-rtemsspe4.12.
Both of those are pretty ugly and confuse the third part.

> It is obvious but if powerpc-*-XXXspe* is the pattern, then the
> spe cases need to be above in all configure switches. I hate to
> mention it but a fair number of odd RTEMS issues turn out to be
> from inadvertent side-effects when cleaning up configure switches.
>
>> Some testcases will be applicable to both ports, some to only one.
>>
>> Maintainers of each port should of course watch the other port for changes
>> that should be carried across, even if we believe, as has been stated in
>> this discussion, that the parts of the code that would be present in both
>> ports are stable and very rarely change.
>>
>
> --joel
>

--joel

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Segher Boessenkool]

On Mon, May 01, 2017 at 10:55:53AM -0500, Joel Sherrill wrote:
> >powerpc-*-rtemsspe* would be OK.
> >
> >powerpc-*-eabisimspe* is pretty ugly though.
> 
> 
> After I sent this, I saw in another response that powerpcspe*-*-*
> was proposed. Is that clearer?

Yes, it does not have part of the architecture name in the OS field ;-)

We can support both: we need to support powerpc*-*-*spe* because that
is what people use today, but we can support powerpcspe-*-* as well.

> For rtems, we already used versioned triplets. powerpc-rtems4.12
> for example. owerpcspe-rtems4.12 seems more correct because spe
> is part of the CPU architecture.
> 
> Otherwise, would it be powerpc-rtems4.12spe or powerpc-rtemsspe4.12.
> Both of those are pretty ugly and confuse the third part.

I agree.  People wanting to match either can use powerpc*-x-x (which
they likely already have because of powerpc64, powerpc64le, powerpcle!)

So if you need to define a new target triple anyway, powerpcspe-*-*
is probably the way to go.


Segher

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Arnaud Charlet]

FWIW, at AdaCore we're using e500v2-wrs-vxworks for our VxWorks
toolchain for SPE.

Arno

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

[Segher Boessenkool]

On Mon, May 01, 2017 at 06:12:37PM +0200, Arnaud Charlet wrote:
> FWIW, at AdaCore we're using e500v2-wrs-vxworks for our VxWorks
> toolchain for SPE.

config.sub translates that to powerpc-wrs-vxworksspe so that works.


Segher