This set of patches is meant to change how we handle selecting the current processor with the -mcpu=<xxx> option in the GCC PowerPC compiler.
I have resubmitted various versions of this patch for some time now. The most recent version was on July 23rd, 2025. * https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690398.html In the previous patch, I put the infrastructure changes along with the CPU option support together in the same patch. In this set of patches, I have split the patches into separate patches. In the previous patch, I implied that we could eliminate in the future the internal -mpower11, -mpower10, -mpower9-misc, and -mpower8-internal option, but it was not part of that patch. This patch set adds patches to eliminate these switches (patches #6 through #10). To be clearer, I have changed the name of what this patch set calls CPU options. Previously, I used hardware ISA. I changed this so I'm using a different phrase that is not ISA. I have bootstrap and ran the regression tests for these patches on both little endian and big endian Power servers. Can I check these patches into the trunk? There are several motivations for this patch: 1: The current processor support used -m<xxx> switches. A lot of these -m<xxx> switches are not meant for users to use, but the current infrastructure requires a dummy -m<xxx> switch to be created. 2: I would like to add support to add a -mcpu=future option to add support for potential new PowerPC support. Note, -mcpu=future is considered experimental additions to the PowerPC architecture. Future machines may use these changes or may add something new. However, it is useful to have a common place for these extensions can be used. 3: If/when a new PowerPC server is announced, we would like add support for this new machine as well. This new interface will simplify adding these new features. As I said before, historically, the PowerPC port has used the ISA flags. These flags are set up based on -m<options> set in rs6000.opt. There are two HOST_WIDE_INT variables for these options: 1: rs6000_isa_flags: These are the current named ISA options that are set for the current build. 2: rs6000_isa_flags_explicit: These are the current name ISA options that were used by the user on the command line. However, the problem with the ISA bits is that you must have a named -m<xxx> option that the user can use on the command line. For example, the -mpopcntd option sets one of the bits for ISA 2.06 features (power7), and -mquad-memory-atomic sets one of the bits for ISA 2.07 features (power8). In general, we don't want the user to be able to say: -mcpu=power9 -mno-popcntd -mno-quad-memory-atomic In addition to ISA options, there is a processor enumeration that says the current processor we are tuning code for. The problem with adding a new processor enumeration is it can be a cascade effect where all code that checks the current processor enumeration now needs to have additional checks added for this new processor. In particular, for adding an option for a potential future processor, you don't want to have a waterfall event where the whole processor is put into the compiler all at once. Instead, what typically happens is the developers add bits and pieces for new instruction set features, and they don't change the scheduling decisions. If the new machine is developed further, eventually changes to the scheduling will need to occur. Logically another problem of using a single value for the processor, and saying if the current processor number is greater than a previous processor, then it has such and such a feature. That is not always guaranteed. For example, there was a version of the power6 architecture that had instructions to copy values between the general purpose registers (GPRs) and floating point registers (FPRs). The power7 architecture that followed the power6 did not have these instructions. Power8 would eventually have similar instructions (called direct move instructions), but these new instructions have different encodings and different capabilities. This means it is best to use a bit-mask like we use for the ISA bits currently to say what the capabilities of the hardware is. This set of patches provides a parallel set of cpu option bits that are only set via the -mcpu=<xxx> option. The user cannot turn these individual cpu options on or off via separate -m<xxx> options. There are ISA options that we want the user to still turn on/off, and these options should remain as -m<xxx> options. Some of these options that the user should be able disable include: -mno-altivec -mno-vsx -mno-mma -mno-crypto -mno-htm -mno-power8-fusion -mno-power10-fusion There are other options historically that were documented as user -m<xxx> options, and because they were documented, they need to remain as -m<xxx> options at the current time. Perhaps these options can be deprecated and removed in future GCC revisions. As these options are removed from GCC, these options should be moved from the ISA flags to the cpu flags. There are 10 patches in this patch set: The first patch provides the basic frame work to add a CPU option field that can be set via -mcpu=<xxx>, and to pass the CPU option field to helper functions much like the current ISA bits are passed. This patch just provides the infrastructure to add this CPU option support. Only power6 through power11 machines have the CPU option set. The second patch will use the new CPU option framework to support the feature: __attribute__((__target_clones__=("cpu=power9,default"))) The third patch will use the new CPU option framework to set the .machine assembler directive for the machines that we have set up CPU options for. The other machines like the Power 750, etc. will continue to use the ISA bits as before. The fourth patch changes the defines of the various _ARCH_PPC<x> macros that have CPU options to use the CPU options instead of ISA bits. The fifth patch adds -mcpu=future. As mentioned earlier, the processor type for scheduling is currently set to power11 instead of making a new processor enumeration. The sixth patch removes the internal -mpower11 ISA option, and it changes to use the CPU option support for testing power11 features. The seventh patch removes the internal -mpower10 ISA option, and it changes to use the CPU option support for testing power10 features. Now, features that showed up in power10 like PC-relative support are left as ISA features, since the user may wish to disable use of PC-relative instructions. The eighth patch removes the internal -mpower9-misc ISA option, and it changes to use the CPU option support for testing power9 features. The ninth patch removes the internal -mpower8-internal ISA option, and it changes to use the CPU option support for testing power8 features. The tenth patch cleans up most of the power7 support not to use -mpopcntd to indicate we are using power7. I believe the -mpopcntd option should be deprecated for GCC 17, but because it is a documented switch, I have left it in these sets of patches. I have made -mpopcntd only restrict uses of the actual popcntd instruction. I have not done an 11th patch to do a similar cleanup for power6 to use the power6 CPU option instead of the -mcmpb. While we can do this in the future, the issue is there are other machines (476, 476fp, and a2) that use the cmpb support, but they have separate processor types. I wasn't sure whether we wanted to add CPU option support for these platforms. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: [email protected]
