Support -mcpu=apple-a12

[fxcoudert]

clang supports passing apple-a12 as a valid CPU choice, probably GCC should align itself with that? Brings trouble in Julia: https://github.com/JuliaLang/julia/issues/44517

[iains]

At present we have no customisation of the CPU profiles for Apple Arm processors. It is something to add, although I am not 100% clear about what is published.

At least we can use the same set of features that clang does (where those are supported).

However things like scheduling etc. are much more complex - and it is hard to see how to implement them without documentation about the chip characteristics.

Courses of action:

• short-term we could accept the option, but essentially use a 'vanilla' chip profile.
• medium-term we could try to map the features at least
• long-term, perhaps we can find enough information to implement a full profile for the chips.

[fxcoudert]

Yes, I think “not erroring out” would already be great.

[giordano]

Note that https://github.com/JuliaLang/julia/pull/44347 changed the flag to -mcpu=apple-m1.

Related question: what would be a good -mcpu value at the moment for this CPU? It isn't quite easy to just guess a close enough CPU from https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

[Bo98]

Related question: what would be a good -mcpu value at the moment for this CPU? It isn't quite easy to just guess a close enough CPU from https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

In terms of -march, in LLVM it's something like -march=armv8.5-a+fullfp16+fp16fml+sha3. I think the GCC equivalent is something like -march=armv8.5-a+fp16+sha3+crypto+rcpc.

-mtune is harder so the safest is probably generic for now.

[iains]

This:

• does not account for cores used in iOS etc.
• proves to be quite tricky, since here is no published info (as far as I know).

Sources of information;

• XNU (only for the Apple Implementer ID)
• sysctl -a | grep hw on various M1 and M2 machines
• AArch64.td from the Apple Open Source repo for LLVM.
• What XCode-14 clang passes to cc1.

Unfortunately, these sources are in conflict; in particular the clang-claimed feature set disagrees with the output of sysctl -a, and the base Arm revs. claimed in some cases miss features that ARM DDI 0487J.a lists as mandatory for the rev.

GCC does not seem to have a scheduler that is similar to the "Cyclone" one in LLVM - so I've guessed to use cortex57 (but, maybe we miss 8-issue, it's not clear - and my experience with the scheduler is ≈ 0).

Thus, the choices here are intended to be conservative.

TODO:

• Currently, we do not seem to have any way to specify that M2 has support for FEAT_BTI, but AFAICT is not compliant with the Arm base rev that implies this.
• No real idea what the version numbers should be, and if there's anywhere we could actually read them.
• Since we have FIRESTORM/ICESTORM and similar pairs for the performance and efficiency cores on various machines, perhaps we should be using a big.LITTLE configuration; OTOH currently, I have no idea if that is usable in any way with our port.