Detection of 'native' CPU

fxcoudert commented 10 months ago

Here's a first attempt calling sysctlbyname("hw.cpufamily", …) At some point, we might want to fill in the blanks for older models, but definitely no hurry :)

fxcoudert commented 10 months ago

Some added notes on https://github.com/iains/gcc-darwin-arm64/commit/43a9cd85686ff5f7446a1129bc1ebf54826e9f59 (aarch64, Darwin: Initial implementation of Apple CPU cores).

For Apple cores, we don't care about the IMP and PART arguments of the AARCH64_CORE macro. They're only used for core identification from /proc/cpuinfo, which we are bypassing.
Alternatively, we could reuse these fields to carry the values of hw.cpufamily (M1, M2, etc) and hw.cpusubfamily (M1, M1 Pro, etc). But I think a simple switch is easier to read and maintain at this stage.

iains commented 10 months ago

I was looking at the big.LITTLE stuff (I.e. where we have performance and efficiency cores), but I do not think that there's any way that we can action it at present.

As far as we might make action at present, the difference between M1 and M2 could be useful (M2 has support for BTI and BF16) but the BTI case is a bit complex since the aarch64 backend assumes it comes with armv8.5 and M2 is mostly armv8.5 but it is missing one mandatory feature (according to the Arm ref. manual) so I've made it as armv8.4+additions.

iains commented 6 months ago

do you think this is something we should try to get into our gcc-14 release? (if so, it presumably needs rebasing)

fxcoudert commented 6 months ago

Nobody has expressed interest so far, so while I think it's a cool feature, it's probably not worth the effort and risk for GCC 14.

iains commented 6 months ago

Nobody has expressed interest so far, so while I think it's a cool feature, it's probably not worth the effort and risk for GCC 14.

however, the Arm folks have added this to their CI .. and it seems that one of the things they did was -mcpu=native. At the moment that has an unfortunate effect; because nothing is found we end up with "" for the cpu, but that overrides the --with-cpu=apple-m1/2 in the configuration. So, it seems likely to be less risky to include this patch than to leave it out.

thoughts?

fxcoudert commented 6 months ago

OK. We should probably add the M3 there. https://github.com/Homebrew/brew/blob/96f861e947e386167fa08475dbd6966aa19cf446/Library/Homebrew/extend/os/mac/hardware/cpu.rb#L118

But it's a rat's race, and we should have a sensible default. What happens if someone passes native and we don't detect the sysctl value?

iains commented 6 months ago

OK. We should probably add the M3 there.

I'll add M3 to the known CPUs shortly (done locally, but I need to rebase and push)

But it's a rat's race, and we should have a sensible default. What happens if someone passes native and we don't detect the sysctl value?

that's a general question about error recovery/fallback - what does the linux impl. do if it encounters an unknown cpu in /proc/.... ?

we could have a fallback to m1, I suppose .. getting early access to h/w info seems unlikely given that it's likely to be held close prior to any release.

fxcoudert commented 6 months ago

Rebased,
Added M3 variants (all named M3 because I don't think we want to have more detail)
Removed older, unused variants

On Linux, host_detect_local_cpu() returns NULL when it has not found sufficient information on what native means. So we'll continue to do the same, it should work. Or we return the oldest known?

Can't test right now, sorry

iains commented 6 months ago

Rebased,

Added M3 variants (all named M3 because I don't think we want to have more detail)

Removed older, unused variants

On Linux, host_detect_local_cpu() returns NULL when it has not found sufficient information on what native means. So we'll continue to do the same, it should work.

Right, actually I suspect it does the unexpected thing of leaving cpu and tune empty - but that's an upstream bug if so... (I'll discuss w/Arm).

Or we return the oldest known?

Let's leave it simple for now - there's actually a bunch more information in addition to the cputype - of we really wanted to try super-hard ..

Can't test right now, sorry

I cannot test M2 or M3 .. but I will pull this patch onto the weekend rebase and ask someone with M3 to try it ...

iains commented 6 months ago

response from IRC: hmm it should only return null on error, when we simply didn't find something we know it returns DEFAULT_ARCH + extensions https://sourcegraph.com/github.com/gcc-mirror/gcc@7d8585c0c0e5934780281abdee256ae6553e56e8/-/blob/gcc/config/aarch64/driver-aarch64.cc?L402

I will take a look at this when adding the patch to the branch (I know you are also busy).

iains commented 6 months ago

https://github.com/iains/gcc-darwin-arm64/commit/9bc66f9b11baf1c291b2afac429cb12bf8461f91 includes the content of this branch.

iains commented 6 months ago

the merged patch has been tested on M1 and M3 - so I think we're all good with this - and maybe a couple of minor tweaks to the code for error checking.

fxcoudert commented 6 months ago

The other uses of this sysctlbyname in the darwin code of GCC expect that it never fails, so I think we're safe, but I'll open a PR to add error checking at some point.

iains commented 5 months ago

I have merged the patch here and added one to select apple-m1 as a default CPU if there is no configure one.

iains / gcc-darwin-arm64

Detection of 'native' CPU #123