apple-m3 detected as the native CPU for nightly rustc on apple-m4

[mmizutani]

I tried the following code with the latest nightly toolchain on a MacBook Pro M4 Max device:

$ rustup run nightly rustc --print target-cpus | head -n2

I expected to see this happen:

The output is expected to be as follows, indicating that the detected CPU is apple-m4.

Available CPUs for this target:
    native          - Select the CPU of the current host (currently apple-m4).

Instead, this happened:

The output indicates that the detected CPU is apple-m3, not apple-m4.

Available CPUs for this target:
    native          - Select the CPU of the current host (currently apple-m3).

The latest nightly rustc does recognize apple-m4 as a valid target-cpu, though:

$ rustup run nightly rustc --print=cfg -C target-cpu=apple-m4 | grep feature
target_feature="aes"
target_feature="bf16"
target_feature="bti"
...
target_feature="wfxt"

Meta

$ rustup run nightly rustc --version --verbose 

rustc 1.85.0-nightly (a47555110 2024-11-22)
binary: rustc
commit-hash: a47555110cf09b3ed59811d9b02235443e76a595
commit-date: 2024-11-22
host: aarch64-apple-darwin
release: 1.85.0-nightly
LLVM version: 19.1.4

$ /usr/sbin/sysctl -n machdep.cpu.brand_string
Apple M4 Max

As was the case in the past similar issue, #127448 (mis-detection of apple-m3 as apple-m2), this might be addressed by an upcoming update to the upstream LLVM.
This fix (llvm/llvm-project#106599) in LLVM 19.x might be relevant.

[madsmtm]

We use LLVM to do our detection, and that will need a similar fix as llvm/llvm-project#82100.

I don't own an M4 myself, so could I get you to run:

$ sysctl hw.cpufamily

Just to make sure what the value actually is?

[madsmtm]

I've submitted llvm/llvm-project#117530, but I'd still like to know the value of sysctl hw.cpufamily, just to make sure that I got it right.

[mmizutani]

@madsmtm
Thanks so much.
Here is the output on a real MacBook Pro M4 Max device:

$ /usr/sbin/sysctl hw.cpufamily
hw.cpufamily: 399882554

(CPUFAMILY_ARM_BRAVA (0x17d5b93a))

[madsmtm]

Great that I asked you, because I didn't actually implement that at first, as that constant was only available in the SDK shipped with Xcode 16.2 beta 3 (and not in Xcode 16.1)! But have done it now, thanks for the help!