platforms: use native arch parameters for apple-m1

[Atemu]

This should allow clang to better optimise for the only aarch64-darwin CPU µarch

Closes #166401

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[lovesegfault]

@Atemu Can you undraft this so reviewers get pinged?

It'd be great to land this :)

[Atemu]

This is untested but sure

[lovesegfault]

Why does ofborg think that this isn't a mass rebuild?

[Atemu]

Perhaps it only checks x86_64-darwin?

[Atemu]

nixpkgs-review reports 28506 packages updated on aarch64-darwin.

[lovesegfault]

IMO we should wait for this staging cycle to end, and then just let this hit staging and see what happens.

I don't think there's another practical way of testing it

[Atemu]

We should also do some benchmarks as µarch optimisations don't necessarily result in a performance improvement.

[vcunat]

We're about to start another staging-next cycle, but I gather that you don't want to merge into this one yet? (I mean, why would you wait otherwise?)

[Atemu]

It's not clear whether this is an improvement yet. We'd have to actually run some benchmarks to get a picture. It might very well cause huge regressions rather than improvements.

I also haven't found the time to do any builds yet, so I don't even know whether anything builds with this applied.

[Atemu]

Yeah, this doesn't even build anything. Clang doesn't know about +fp-armv8+neon+zcm+zcz+fullfp16 and yet it is able to use these as target-flags when called differently? I don't understand it.

I'm not sure this is worthwhile pursuing but I'll try to build a few benchmarks with the improved but reduced set.

I'm also not quite sure whether it makes sense to set arch and cpu differently. Shouldn't these flags go in CPU only?

[Atemu]

I don't plan on pursuing this any further.