apple-m1 compiler optimisations for aarch64-darwin?

[Atemu]

Issue description

nixpkgs/lib/systems/platforms.nix

Lines 393 to 398 in dd697d4

	apple-m1 = {
	gcc = {
	arch = "armv8.3-a+crypto+sha2+aes+crc+fp16+lse+simd+ras+rdm+rcpc";
	cpu = "apple-a13";
	};
	};

adds inappropriate arch args for apple-m1. According to Apple clang, arch = "armv8.5a+fp-armv8+neon+crc+crypto+dotprod+fp16fml+ras+lse+rdm+rcpc+zcm+zcz+fullfp16+sm4+sha3+sha2+aes";.

(The string isn't even correct for apple-13 AFAICT, it's armv8.4a.)

Is there any reason against setting arch to the string above?

Secondly, is there any reason against setting cpu = "apple-m1"; once llvm12 is default? llvm11 doesn't support that cpu type; what would happen if a package's llvm was overridden to be llvm11?

cc @thefloweringash @NixOS/darwin-maintainers

[thefloweringash]

The current flags come from #105026 (comment) by @bobrik.

Is there any reason against setting arch to the string above?

Not that I know of.

Secondly, is there any reason against setting cpu = "apple-m1"; once llvm12 is default?

That does also sound like an improvement, and might even resolve the TODO items added in 4aa95e3 (#115235 (comment)). We could probably handle llvm11 compatibility in the cc-wrapper as a special case, if it's still needed. I don't expect there to be a large difference between llvm11 and llvm12.

Though we made a concession to llvm11 to revert the new default setting of -fno-common (c99904e). We'd either need to make the same change in llvm12, or progress #110571.

[Atemu]

@thefloweringash fno-common migration is merged. Does that mean we can upgrade llvm to 12 (or higher?) for aarch64-darwin?

[toonn]

Main blocker rn would be we can't upgrade the LLVM in the bootstraptools currently, relevant information linked from this PR.

[thefloweringash]

@thefloweringash fno-common migration is merged. Does that mean we can upgrade llvm to 12 (or higher?) for aarch64-darwin?

I don't know of any significant blockers.

Main blocker rn would be we can't upgrade the LLVM in the bootstraptools currently, relevant information linked from this PR.

Hopefully we don't have to update the bootstrap tools to update to a new version of llvm. The main part I don't know how to handle is the contents of this issue. For llvm that supports it, we want to use "apple-m1", but while bootstrapping from the older version (and presumably also for gcc) we'd need to provide a string the compiler understands.

[toonn]

@thefloweringash, you want to update stdenv LLVM without bumping the version in the bootstrap-tools?

[thefloweringash]

@thefloweringash, you want to update stdenv LLVM without bumping the version in the bootstrap-tools?

I have seen nixpkgs use llvm v4 in bootstrap tools and llvm v7 in the stdenv. It should be possible to bootstrap llvm like this. I'm not advocating for it though, and in general I don't mind updating bootstrap tools more frequently if it makes things easier.