The CPU table lacked the Apple M2 Pro/Max cores (MIDR part 0x038/0x039),
so they were reported as "Unidentified cores" and the JIT fell back to a
generic -mcpu=cortex-a78. Add those parts and a new aarch64::get_cpu_llvm_name()
that maps the detected Apple SoC family to the matching LLVM CPU
(apple-m1..m4); fallback_cpu_detection() now uses it so the recompilers get
the correct scheduling model on Apple silicon instead of a generic core.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Some SPU programs inexplicably fail to compile when TBL2/TBX2 are used.
- As an insane workaround, first try to compile with TBL2/TBX2, if LLVM crashes while compiling, try to compile the same program without TBL2/TBX2.
Build RPCS3 / RPCS3 Mac ${{ matrix.name }} (1, 8e21bdbc40711a3fccd18fbf17b742348b0f4281, rpcs3/rpcs3-binaries-mac-arm64, Apple Silicon) (push) Waiting to run
- On x86, LLVM has robust detection for the CPU name. If a CPU like skylake has AVX disabled, it will fall back to something without AVX (nehalem)
- On ARM, detection is not as robust. For instance, on my snapdragon 8 gen 2, it assumes that we have SVE support, as the cortex-x3 supports SVE.
- If an ARM cpu is paired with other cpus from another generation which doesn't support the same instructions as the cortex-x3, or if the cortex-x3 just has SVE disabled for no apparant reason (in the case of the snapdragon 8 gen 2)
- We need to actually detect that ourselves.
- Beyond SVE also detect support for some instructions that might be useful SPU LLVM when optimized with intrinsics.
