mbox series

[0/9] Adding PowerPC architecture flags in addition to ISA flags

Message ID Zqx2ORkY5kAGF4XW@cowardly-lion.the-meissners.org
Headers show
Series Adding PowerPC architecture flags in addition to ISA flags | expand

Message

Michael Meissner Aug. 2, 2024, 6:01 a.m. UTC 
I wrote these patches after submitting the power11 patches.

For a long time, one of the issues with the PowerPC port has been internally we
use an ISA option to denote a specific power architecture level.

For example:

	-mpopcntb	means the target is at least a power5 system
	-mfprnd		means the target is at least a power5+ system
	-mcmpb		means the target is at least a power6 system
	-mpopcntd	means the target is at least a power7 system
	-mmodulo	means the target is at least a power9 system

Several times we have needed to add support for an architecture in general, but
we don't have a specific new ISA flag for the architecture.  This means we have
to add undocumented ISA options in order to set an ISA flag.  We then have to
mark the option so that the user should not use these options.

	-mpower8-internal	means the target is at least a power8 system
	-mpower10		means the target is at least a power10 system
	-mpower11		means the target is at least a power11 system

Instead of using these ISA switches, the user should use the appropriate
-mcpu=<proc> and -mtune=<proc> options, and let the compiler enable all of the
appropriate options.  As needed, the user can use the ISA options to restrict
the code generation (for example using -mno-vsx).

So these patches are a general cleanup to move the hardware options that aren't
an ISA option into a separate hardware.  It also will change the GCC compiler
so that it now uses TARGET_POWER7 instead of TARGET_POPCNTD.

In addition, these patches also change the behavior of the GCC compiler so that
-mvsx does not automatically raise a default build to target power7 and later.
This shows up on big endian systems where the default cpu for GCC is power4.

Parts of this issue shows up in building the IEEE 128-bit floating point
support on systems that do not support VSX, which is needed for IEEE 128-bit
floating point.  PRs target/115800 and target/113652 have been raised for
problems caused in building GCC on some systems and I have submitted patches
for libgfortran and libstdc++-v3 (basically on these patches, if the compiler
does not support IEEE 128-bit by default, do not build the IEEE 128-bit
support).

The patches in this set of patches will now give an error if you use -mvsx when
the default cpu is not at least power7.

The patches in this set are:

   #1	This patch adds support for the architecture flags.  It also moves the
	target_clones support to use the architecture flags.  For the power
	processors, the .machine directive now uses the architecture flags.

   #2	This patch removes -mpower8-internal, -mpower10, and -mpower11 from
	being ISA flag bits, and the appropriate support uses the architecture
	flag bits.

   #3	This patch prevents newer ISA options from implicitly raising the CPU.
	In particular, it prevents -mvsx from being used if the processor does
	not support VSX (i.e. power7 or newer).

   #4	This patch changes most uses of TARGET_POPCNTB to TARGET_POWER5.  In
	places where the code is explicitly about the popcount instruction, I
	did not change the references.

   #5	This patch changes TARGET_FPRND to TARGET_POWER5X.

   #6	This patch changes TARGET_CMPB to TARGET_POWER6.

   #7	This patch changes TARGET_POPCNTD to TARGET_POWER7, except in the
	places where the code explicitly handles the popcount instruction.

   #8	This patch changes TARGET_MODULO to TARGET_POWER9, except in the places
	where the code explicitly handles the modulo instruction.

   #9	This patch fixes the two tests that needed to use -mcpu= to use an
	option like -mvsx.

I have built both big endian and little endian bootstrap compilers and there
were no regressions.

In addition, I constructed a test case that used every archiecture define (like
_ARCH_PWR4, etc.) and I also looked at the .machine directive generated.  I ran
this test for all supported combinations of -mcpu, big/little endian, and 32/64
bit support.  Every single instance generated exactly the same code with the
patches installed compared to the compiler before installing the patches.

Can I install these nine patches on the GCC 15 trunk?