move -mcpu to be part of the target triple

[andrewrk]

This is a follow-up issue from #4550.

std.zig.CrossTarget has the ability to represent CPU features, as well as std.Target.

Curently, "parsing" a target triple also wants to know the CPU model name and feature set at the same time, in order to produce a target. So this is a proposal to merge the concepts together. It mainly involves the CLI.

The proposal is to change this (example):

-target arm-linux-gnu -mcpu=generic+v8a-neon

to this:

-target arm.generic+v8a~neon-linux-gnu

The main idea here is that -mcpu is deleted as a command line parameter, and -target gains even more expressiveness.

This works by replacing - with ~, because - is a field separator in the -target command line parameter. This would not affect the #3089 CLI which would have -mcpu to match C compilers. Note that ~ means "binary not" in many contexts, which would be a reasonable mnemonic to remember the syntax by.

The main area where this would be helpful would be the Zig build system, because standardTargetOptions would only need to be concerned with -Dtarget rather than -Dtarget and -Dmcpu. The fact that CPU features are part of both std.Target and std.zig.CrossTarget is a strong hint that this data belongs together.

As another example, std.zig.CrossTarget.parse wants to know the -mcpu parameter in order to produce a result:

https://github.com/ziglang/zig/blob/7e6b68a534f840d2d08770a5a77896707271e8ea/lib/std/zig/cross_target.zig#L168-L219

[rohlem]

EDIT: Resolved, I misread the proposed structure... several times over...

[daurnimator]

The main area where this would be helpful would be the Zig build system, because standardTargetOptions would only need to be concerned with -Dtarget rather than -Dtarget and -Dmcpu. The fact that CPU features are part of both std.Target and std.zig.CrossTarget is a strong hint that this data belongs together.

As far as I can see, standardTargetOptions doesn't currently support -Dmcpu either, and hence there is no way to pass a model?

[ikskuh]

Argument for status quo:

zig … -target x86_64.nehalem+sgx+sse3+tsxldtrk~prefer_128_bit-linux.4.13-gnueabihf …

I cannot really read that compared to a -target x86_64-linux.4.13-gnueabihf And even that is not really well readable, i'd even prefer to put OS version into a separate command line flag and just have -target x86_64-linux-gnueabihf

[jaredkrinke]

Does the current behavior prevent zig cc from being able to cross-compile to a Raspberry Pi B (armv6l)? If so, are there any workarounds?

I came to this issue from #4875 and I'm seeing the same behavior as reported there: zig cc interprets "arm" as "armv7", and I don't see a way to tell it to target "armv6l" instead (contrast with zig build, where -Dcpu=arm1176jzf_s for Raspberry Pi B works great).