Commit Message
Hi!
This adds more correct .machine for most older CPUs. It should be
conservative in the sense that everything we handled before we handle at
least as well now. This does not yet revamp the server CPU handling, it
is too risky at this point in time.
Tested on powerpc64-linux {-m32,-m64}. Also manually tested with all
-mcpu=, and the output of that passed through the GNU assembler.
I plan to commit this later today.
Segher
2022-03-04 Segher Boessenkool <segher@kernel.crashing.org>
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Restructure a bit.
Handle most older CPUs.
---
gcc/config/rs6000/rs6000.cc | 69 +++++++++++++++++++++++++++++++--------------
1 file changed, 48 insertions(+), 21 deletions(-)
Comments
This breaks the build of libgcc for powerpc-linux-gnu (32-bit, default
CPU; configured --disable-multilib --enable-secureplt).
cc1: warning: The '-mfloat128' option may not be fully supported
/tmp/ccHCPzSh.s: Assembler messages:
/tmp/ccHCPzSh.s:163: Error: unrecognized opcode: `lfiwzx'
/scratch/jmyers/glibc-bot/src/gcc/libgcc/shared-object.mk:14: recipe for target '_kf_to_sd.o' failed
make[3]: *** [_kf_to_sd.o] Error 1
https://sourceware.org/pipermail/libc-testresults/2022q1/009421.html
On Mon, Mar 07, 2022 at 08:53:42PM +0000, Joseph Myers wrote:
> This breaks the build of libgcc for powerpc-linux-gnu (32-bit, default
> CPU; configured --disable-multilib --enable-secureplt).
>
> cc1: warning: The '-mfloat128' option may not be fully supported
> /tmp/ccHCPzSh.s: Assembler messages:
> /tmp/ccHCPzSh.s:163: Error: unrecognized opcode: `lfiwzx'
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/shared-object.mk:14: recipe for target '_kf_to_sd.o' failed
> make[3]: *** [_kf_to_sd.o] Error 1
>
> https://sourceware.org/pipermail/libc-testresults/2022q1/009421.html
Thanks for the report! This is now PR104829.
Segher
On 04/03/2022 17:51, Segher Boessenkool wrote:
> Hi!
>
> This adds more correct .machine for most older CPUs. It should be
> conservative in the sense that everything we handled before we handle at
> least as well now. This does not yet revamp the server CPU handling, it
> is too risky at this point in time.
>
> Tested on powerpc64-linux {-m32,-m64}. Also manually tested with all
> -mcpu=, and the output of that passed through the GNU assembler.
>
> I plan to commit this later today.
Could this be back ported to GCC 10 and 11? I would fix the following
issue for -mcpu=405:
Error: unrecognized opcode: `dlmzb.'
Hi!
On Thu, Mar 10, 2022 at 09:25:21AM +0100, Sebastian Huber wrote:
> On 04/03/2022 17:51, Segher Boessenkool wrote:
> >This adds more correct .machine for most older CPUs. It should be
> >conservative in the sense that everything we handled before we handle at
> >least as well now. This does not yet revamp the server CPU handling, it
> >is too risky at this point in time.
> >
> >Tested on powerpc64-linux {-m32,-m64}. Also manually tested with all
> >-mcpu=, and the output of that passed through the GNU assembler.
> >
> >I plan to commit this later today.
>
> Could this be back ported to GCC 10 and 11? I would fix the following
> issue for -mcpu=405:
>
> Error: unrecognized opcode: `dlmzb.'
Good to hear!
Unfortunately there is PR104829 about this commit. I don't see how the
commit can break anything (that wasn't already broken); it's not clear
how it happens at all, and neither me nor colleagues could reproduce it
so far.
So I won't yet backport it, but first wait what happens here.
Thanks for the report,
Segher
Hello Segher,
On 10/03/2022 11:11, Segher Boessenkool wrote:
> On Thu, Mar 10, 2022 at 09:25:21AM +0100, Sebastian Huber wrote:
>> On 04/03/2022 17:51, Segher Boessenkool wrote:
>>> This adds more correct .machine for most older CPUs. It should be
>>> conservative in the sense that everything we handled before we handle at
>>> least as well now. This does not yet revamp the server CPU handling, it
>>> is too risky at this point in time.
>>>
>>> Tested on powerpc64-linux {-m32,-m64}. Also manually tested with all
>>> -mcpu=, and the output of that passed through the GNU assembler.
>>>
>>> I plan to commit this later today.
>> Could this be back ported to GCC 10 and 11? I would fix the following
>> issue for -mcpu=405:
>>
>> Error: unrecognized opcode: `dlmzb.'
> Good to hear!
>
> Unfortunately there is PR104829 about this commit. I don't see how the
> commit can break anything (that wasn't already broken); it's not clear
> how it happens at all, and neither me nor colleagues could reproduce it
> so far.
>
> So I won't yet backport it, but first wait what happens here.
now that the PR104829 is fixed could I back port
Segher Boessenkool (2):
rs6000: Improve .machine
rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
to GCC 10 and 11?
Hi!
On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
> now that the PR104829 is fixed could I back port
>
> Segher Boessenkool (2):
> rs6000: Improve .machine
> rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
>
> to GCC 10 and 11?
I will do it, in a few days though.
Thanks for your enthusiasm :-),
Segher
Hello Segher,
On 15/03/2022 23:29, Segher Boessenkool wrote:
> On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
>> now that the PR104829 is fixed could I back port
>>
>> Segher Boessenkool (2):
>> rs6000: Improve .machine
>> rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
>>
>> to GCC 10 and 11?
> I will do it, in a few days though.
>
> Thanks for your enthusiasm :-),
would now be a good time to back port the fixes or do you want to wait
for the GCC 12 release? I would be nice if the fixes are included in the
GCC 10.4 release.
On 04/04/2022 11:31, Sebastian Huber wrote:
> Hello Segher,
>
> On 15/03/2022 23:29, Segher Boessenkool wrote:
>> On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
>>> now that the PR104829 is fixed could I back port
>>>
>>> Segher Boessenkool (2):
>>> rs6000: Improve .machine
>>> rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
>>>
>>> to GCC 10 and 11?
>> I will do it, in a few days though.
>>
>> Thanks for your enthusiasm :-),
>
> would now be a good time to back port the fixes or do you want to wait
> for the GCC 12 release? I would be nice if the fixes are included in the
> GCC 10.4 release.
The GCC 10.4 release candidate will be made on 21st June. May I pack
port the two patches today?
On Mon, Jun 20, 2022 at 09:48:34AM +0200, Sebastian Huber wrote:
> On 04/04/2022 11:31, Sebastian Huber wrote:
> >Hello Segher,
> >
> >On 15/03/2022 23:29, Segher Boessenkool wrote:
> >>On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
> >>>now that the PR104829 is fixed could I back port
> >>>
> >>>Segher Boessenkool (2):
> >>> rs6000: Improve .machine
> >>> rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
> >>>
> >>>to GCC 10 and 11?
> >>I will do it, in a few days though.
> >>
> >>Thanks for your enthusiasm :-),
> >
> >would now be a good time to back port the fixes or do you want to wait
> >for the GCC 12 release? I would be nice if the fixes are included in the
> >GCC 10.4 release.
>
> The GCC 10.4 release candidate will be made on 21st June. May I pack
> port the two patches today?
Yes. Thanks!
Segher
@@ -5790,33 +5790,60 @@ const char *rs6000_machine;
const char *
rs6000_machine_from_flags (void)
{
- /* For some CPUs, the machine cannot be determined by ISA flags. We have to
- check them first. */
- switch (rs6000_cpu)
- {
- case PROCESSOR_PPC8540:
- case PROCESSOR_PPC8548:
- return "e500";
+ /* e300 and e500 */
+ if (rs6000_cpu == PROCESSOR_PPCE300C2 || rs6000_cpu == PROCESSOR_PPCE300C3)
+ return "e300";
+ if (rs6000_cpu == PROCESSOR_PPC8540 || rs6000_cpu == PROCESSOR_PPC8548)
+ return "e500";
+ if (rs6000_cpu == PROCESSOR_PPCE500MC)
+ return "e500mc";
+ if (rs6000_cpu == PROCESSOR_PPCE500MC64)
+ return "e500mc64";
+ if (rs6000_cpu == PROCESSOR_PPCE5500)
+ return "e5500";
+ if (rs6000_cpu == PROCESSOR_PPCE6500)
+ return "e6500";
- case PROCESSOR_PPCE300C2:
- case PROCESSOR_PPCE300C3:
- return "e300";
+ /* 400 series */
+ if (rs6000_cpu == PROCESSOR_PPC403)
+ return "\"403\"";
+ if (rs6000_cpu == PROCESSOR_PPC405)
+ return "\"405\"";
+ if (rs6000_cpu == PROCESSOR_PPC440)
+ return "\"440\"";
+ if (rs6000_cpu == PROCESSOR_PPC476)
+ return "\"476\"";
- case PROCESSOR_PPCE500MC:
- return "e500mc";
+ /* A2 */
+ if (rs6000_cpu == PROCESSOR_PPCA2)
+ return "a2";
- case PROCESSOR_PPCE500MC64:
- return "e500mc64";
+ /* Cell BE */
+ if (rs6000_cpu == PROCESSOR_CELL)
+ return "cell";
- case PROCESSOR_PPCE5500:
- return "e5500";
+ /* Titan */
+ if (rs6000_cpu == PROCESSOR_TITAN)
+ return "titan";
- case PROCESSOR_PPCE6500:
- return "e6500";
+ /* 500 series and 800 series */
+ if (rs6000_cpu == PROCESSOR_MPCCORE)
+ return "\"821\"";
- default:
- break;
- }
+ /* 600 series and 700 series, "classic" */
+ if (rs6000_cpu == PROCESSOR_PPC601 || rs6000_cpu == PROCESSOR_PPC603
+ || rs6000_cpu == PROCESSOR_PPC604 || rs6000_cpu == PROCESSOR_PPC604e
+ || rs6000_cpu == PROCESSOR_PPC750 || rs6000_cpu == PROCESSOR_POWERPC)
+ return "ppc";
+
+ /* Classic with AltiVec, "G4" */
+ if (rs6000_cpu == PROCESSOR_PPC7400 || rs6000_cpu == PROCESSOR_PPC7450)
+ return "\"7450\"";
+
+ /* The older 64-bit CPUs */
+ if (rs6000_cpu == PROCESSOR_PPC620 || rs6000_cpu == PROCESSOR_PPC630
+ || rs6000_cpu == PROCESSOR_RS64A || rs6000_cpu == PROCESSOR_POWERPC64)
+ return "ppc64";
HOST_WIDE_INT flags = rs6000_isa_flags;