Our x86-32 target names are inconsistent

[RalfJung]

The typical naming scheme we use for x86-32 targets is:

• i686 means Pentium 4 (yes that makes no sense but, well, it's too disruptive to change now and i786 didn't catch on as a name anywhere), which in particular have SSE2
• i586 means "original Pentium" (no SSE)

We have some targets that violate this:

• i686-linux-android is actually PentiumPro with SSE, but that seems sufficiently close to Pentium 4 that it's still the right name IMO (in particular, it does have more vector extensions than Pentium 4; not sure why we are using "Pentium Pro" as the baseline) (resolved by i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change #136885)
• i386-apple-ios uses Penryn as baseline, way newer than Pentium 4, so of course it has SSE (this target is ancient, it predates Rust 1.0)
• i586-pc-nto-qnx700 uses Pentium 4 as baseline (resolved by Make x86 QNX target name consistent with other Rust targets #137324)
• i686-unknown-hurd-gnu uses PentiumPro without SSE as baseline (resolved by i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4 #136700)
• i686-unknown-redox uses PentiumPro without SSE as baseline (resolved by Replace i686-unknown-redox target with i586-unknown-redox #136698)

If we want to establish the pattern that "i686 has SSE and the rest does not", then the last four of these should be renamed. (These are all tier 3 targets.) I wonder if there is a specific reason that these names were picked diverging from our usual naming scheme, or is it just an oversight because our naming scheme is admittedly not very self-explaining?

• The Apple target is ancient and I assume was picked for consistency with how Apple calls this -- not sure if that should overwrite our own naming scheme.
• For Hurd and Redox, we have no other targets that use PentiumPro without SSE as baseline, so it's a bit unclear what one would even use -- they are somewhere between i586 (original Pentium) and what we call i686 (Pentium 4). The most consistent outcome here would be to use Pentium 4 as the baseline like we use for all other OSes; not sure why Hurd and Redox should be special.
• The i586-pc-nto-qnx700 one however should almost certainly be called i686.

Pinging the listed target maintainers and some other folks:
Cc @bjorn3 @workingjubilee @badboy @deg4uss3r @madsmtm @sthibaul @jackpot51 @flba-eb @gh-tr @jonathanpallant @japaric

[jonathanpallant]

For QNX Neutrino 7.0.0, that is the name that Blackberry QNX use for their C toolchain:

~/qnx700/host/darwin/x86_64/usr/bin/i586-pc-nto-qnx7.0.0-ld

I think the primary question you all need to ask yourselves is:

• Is it better for targets to be internally consistent (i.e. within rustc), or is it better for each target be consistent with other toolchains for that target

I've already had this argument about arm64e-apple-darwin (which in my view should have been aarch64-apple-darwin-something), and I lost. But maybe you'll have another ticket for the Arm 64-bit targets.

[RalfJung]

I was wondering about the arm64e prefix... but I didn't plan to check all our targets, now. I am too scared of what I may find. ;)

[bjorn3]

arm64ec-pc-windows-msvc is similar in weird naming, though it's behavior is much less cursed than in C where it literally makes target detection using macros think it is running on x86 with x86 vendor intrinsics emulated by the compiler.

[sthibaul]

For the last 2, we have no other targets that use PentiumPro without SSE as baseline

I don't remember the details, but basically we targetted i686 as defined in Debian:

https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1

(and also gcc)

The most consistent outcome here would be to use Pentium 4 as the baseline like we use for all other OSes

? That would assume SSE2, which is wrong? #82435 (only pentium-M has SSE2)

Adding MMX and SSE should however be fine enough, even if the very original pentiumpro didn't have them.

[workingjubilee]

Debian also advises that you not use a CPU less than Pentium 4.

[sthibaul]

Debian also advises that you not use a CPU less than Pentium 4.

This is just a recommendation.

Debian can actually be used on way less-powered i686 systems if you stick to a minimal system. But you cannot expect to be able to do what you were used to be doing 20 years ago with the Debian distribution at the time: code has gotten much larger.

[workingjubilee]

For note: Currently, the Debian-distributed rustc patches our i686-unknown-linux-gnu to use Pentium Pros instead of Pentium 4s. This results in them getting bugs and test failures in Rust code because the code generation doesn't use SSE2 registers, thus is unsound due to various bugs in LLVM (and while I am told GCC is better, I'm not entirely sure). They then report this to crate maintainers. The crate maintainers, having deliberately developed against i686-unknown-linux-gnu as per rustc's definition, get very confused. They then get annoyed, when they find out this is entirely caused by Debian's insistence on divergence from rustc's definitions.

Unfortunately using real CPU names in targets like perhaps pentium4-unknown-linux-gnu didn't catch on, and neither did tuples like i786-unknown-linux-gnu (even if they are technically recognized by Autotools).

[sthibaul]

this is entirely caused by Debian's insistence on divergence from rustc's definitions

You mean caused by rust's insistence on assuming that i686 has SSE2.

[workingjubilee]

Debian calls this architecture i386, but Debian will not run on an i386 CPU.

If you prefer, I could say, "Debian's insistence on making code unsound".

[sthibaul]

Debian calls this architecture i386

Yes, because changing the name would have meant people having to reinstall their system. The meaning of the "i386" port has changed with the reasonable hardware that you can really run indeed.

If you prefer, I could say, "Debian's insistence on making code unsound".

Where "unsound" is wholy defined by rust, which wrongly insist on i686 having SSE2.

Anyway, let's not just rehash #82435

[RalfJung]

Yes, Rust's name "i686" is inconsistent with how other parts of the ecosystem use that term. That's not great, but indeed that's #82435. But i686 consistently means "Pentium 4" for almost all Rust targets, so unless there are good reasons IMO Hurd and Redox should follow suit. Debian's use of the term is not as relevant here as precedent within Rust itself.

[sthibaul]

unless there are good reasons IMO Hurd and Redox should follow suit.

I exposed what I believe are good reasons. Then it's up to rust maintainers to consistently remain inconsistent.

[madsmtm]

i386-apple-ios
The Apple target is ancient and I assume was picked for consistency with how Apple calls this -- not sure if that should overwrite our own naming scheme.

I wasn't there when it was introduced, but I'd guess that it was for consistency with Clang, yeah. The target is mostly legacy nowadays though, and might be gone the next time we bump supported versions, I don't think there is that much value in renaming it.

(I'd rather rename aarch64-apple-darwin to aarch64-apple-macos, or even better aarch64-macos, but that's much more difficult).

[RalfJung]

I exposed what I believe are good reasons.

So the reason is "because Debian defines i686 that way"? It wasn't clear to me whether that was meant to be informational, or justification for how Rust defines its built-in targets. It also doesn't give a reason for why Hurd/Redox should be different than Linux/FreeBSD/NetBSD/OpenBSD.

[sthibaul]

So the reason is "because Debian defines i686 that way"?

No. "because i686 normally doesn't have SSE2". I mentioned Debian's target as an explanation why it was done so originally. And then brought arguments why one could want to remain so.

why Hurd/Redox should be different than Linux/FreeBSD/NetBSD/OpenBSD.

Because it's technically wrong to say that i686 has SSE2.

But again, I'm not a maincore rust maintainer. I have no will to fight over such a thing. I'm asked my opinion for the reason, I give it, that's all.

[workingjubilee]

Where "unsound" is wholy defined by rust, which wrongly insist on i686 having SSE2.

No.

@sthibaul: Rust defines f32 and f64 to be IEEE754 binary32 and binary64 floating point numbers, and with SSE2 registers, this is correctly implemented. But LLVM does not compile code using the x87 float registers correctly. LLVM does not even compile such code in a way consistent with any sort of use of an "extended precision" scheme that might be justifiable in C, since it introduces various classic errors like double rounding or spontaneous truncation that corrupts the floating point value, which should simply not occur. We have gone to great lengths to try to eliminate the usage of any of the floating point registers for 32-bit x86 targets which do not have SSE2, at least when Rust calls Rust.

In other words #82435 is not a random bug, it is intimately related to #114479 existing. Fixes for this situation are underway but implementing them will not help if Debian maintainers pretend their choices are merely about nomenclature and patch them out, just like they patched the target's target_cpu string. If you want to insist on a certain naming scheme, that's one thing, but it needs to be done with full awareness that what you are tampering with can affect program correctness negatively.

[sthibaul]

Where "unsound" is wholy defined by rust, which wrongly insist on i686 having SSE2.

No.

Well, "yes". Various i686 processors do not have SSE2, and that can pose real problem: your program just crashes.

I completely understand that not having SSE2 can pose floating point issues, and that it becomes reasonable for rust to just requires SSE2. Simply, technically it's not i686 any more.

Again, I'm just asked my opinion on this, so I give it. I can understand that there are more important problems that assuming SSE2 solves, and using i786 would pose other issues, and I'm fine with bumping to SSE2 due to this. But don't make me eat that i686 always has SSE2. It doesn't.

Debian maintainers pretend their choices are merely about nomenclature

It's not about nomenclature. It's about not seeing gnome-shell starting to crash inside librsvg just after a mere software upgrade.

[jackpot51]

As the maintainer of Redox and an owner of a Pentium II - I must stress that i686 identifies the P6 microarchitecture, used by the Pentium Pro, Pentium II, and Pentium III, which did not come with SSE of any kind until the Pentium III. This is the current baseline of the Redox operating system, and I'd prefer it remains that way.

[beetrees]

I think the most important thing is for Rust to be consistent with itself: if other tools/distributions have a different ideas of what i[34567]86 mean, then they should be able to have a single mapping from their meanings to Rust's meanings, rather than having to depend on different mappings per target. Given that all tier 1/2 targets use the definitions of i586/i686 as described in the OP (and it was decided not to change this in #82435), I think the inconsistent tier 3 targets should be renamed to be consistent. Given the longstanding miscompilations with non-SSE2 floating point numbers, I think it's also useful to be able to say "only i586-* targets have the unsound miscompilations tracked in #114479".

(As a side note, does anyone know of any reason why Debian doesn't use the i586-unknown-linux-gnu target instead of patching the compiler?)

[RalfJung]

(As a side note, does anyone know of any reason why Debian doesn't use the i586-unknown-linux-gnu target instead of patching the compiler?)

That lowers the baseline down to the original Pentium, which I think is lowering it further than they want to.

I must stress that i686 identifies the P6 microarchitecture, used by the Pentium Pro, Pentium II, and Pentium III, which did not come with SSE of any kind until the Pentium III. This is the current baseline of the Redox operating system, and I'd prefer it remains that way.

Understood. However, Redox doesn't get to define the baseline supported by the Rust compiler. Everything older than the Pentium 4 is considered unsupported (tier 3 at most) by the Rust project, simply because the x87 FPU is so poorly behaved that it'd be a lot of work to make LLVM work correctly there, and nobody seems to be willing to put in that work.

Now, Redox already is a tier 3 target, so the only immediate consequence of this is that the target has no way of becoming a tier 2 target in its current form. However, it's also not great when tier 3 targets cause confusion by using terminology in a different way than what we established for our tier 1 & 2 targets. If I had a time machine I'd propose renaming the i686 targets to i786, though I imagine that would also cause enough problems to not be an obvious win, so for better or worse we use i686 to refer to Pentium 4. (This kind of mismatch is not unique to Rust; i386 is used by Debian and Apple to refer to things way newer than the original i386 CPU, and apparently QNX uses i586 to refer to a Pentium 4. Clang ignores the N in "iN86" entirely and always assumes a Pentium 4. So it's just not correct to claim that there is a coherent idea across the ecosystem of what i686 would mean, or what "at least Pentium 4" should be called.)

So IMO either the redox target should be renamed, or it should use the Pentium 4 baseline. (And same for the hurd target.) You seem to prefer a rename; the main challenge here is finding a good name.

[RalfJung]

Regarding the Android target, @maurer do you know if there is a reason that it uses pentiumpro rather than pentium4 as the baseline CPU? The features it then enables go well beyond what even the Pentium 4 had.

[workingjubilee]

To restate my point another way: When anyone involved in this mess insists on a particular definition for a term already in use elsewhere, citing an imagined consensus that the definition is correct according to some convention, they expose themselves to others insisting on a different definition. It doesn't matter which is right or wrong, because when it then comes to a third party, that party cannot conform to two definitions at once and still make sense. And at the risk of sounding overly cynical, as long as there are two people who claim they get to define the term... which includes "every Linux distro"... then we will be wrong according to one.

Some of the decisions we have made have been an attempt to be consistent with external toolchains. However, I don't believe it's very useful to try to be consistent with these external toolchains when the inevitability is that eventually we become inconsistent with them anyways. Any scheme we might imagine to be "consistent" can be patched into inconsistency by others, because it makes a program "work", even if the resulting program is not actually sound. We cannot rely on them to tell us, either, when they patch rustc.

In other words, I agree that we must consider ourselves the final authority on what a target tuple's name means. If we happen to find it useful to match the meanings of someone else, then we should only do so as long as it preserves our own self-consistency. Due to various patches and inconsistencies "in the wild", we cannot really save people from the need to map tuples in various ways.

[maurer]

Regarding the Android target, @maurer do you know if there is a reason that it uses pentiumpro rather than pentium4 as the baseline CPU? The features it then enables go well beyond what even the Pentium 4 had.

tl;dr: Using pentium4 + sse3 should be safe for Android.

Sorry for the late reply. The line here for Android is that it's barebones x86, plus "MMX, SSE, SSE2, SSE3, and SSSE3". It's phrased this way rather than to a specific CPU baseline because we're trying to describe what is guaranteed to be available to an app when it runs, not a specific CPU, and "pentium 4" is not an instruction set. Pentium 4s only ever had mmx/sse/sse2/sse3, so any interpretation of this will only select instructions available on all Android devices.

The platform's current minimum architecture is prescott, so the platform does not consider CPUs older than the Pentium 4. The last time it's possible anything earlier than prescott was considered was older than 2015 - I can do more digging if you want to check for sure, but I'm pretty sure that prescott and atom are the minimum we've ever built for.

[apiraino]

T-compiler had a look at this discussion thread last week (on Zulip). TL;DR is that we're fine proceeding with improving naming consistency, where it makes it more aligned with the vendor idea of that target naming.

@rustbot label -I-compiler-nominated

[RalfJung]

@apiraino that doesn't really answer the main remaining question which is what to do with targets where the vendor naming directly conflicts our own naming conventions.

[apiraino]

sorry Ralf. Here's perhaps a better excerpt:

[...] when the vendor has made a clear decision regarding target naming, it's more important to be consistent with that (and thus the wider software ecosystem).

About i686:

I'm not sure that applies in the i686 case since so many different vendors have very different ideas about what that means. (It might be interesting to see what Intel's compiler does when asked to produce i686 code)

[RalfJung]

The concrete remaining cases are i386 and i586 being used by vendors to refer to things that are on the level of Pentium 4 or higher. The i386 target apparently might disappear soon anyway, so really it's just about the one i586 target that clashes with how we use i586 for other targets.

[RalfJung]

I re-added the nomination, to answer the very concrete question of what to do with i586-pc-nto-qnx700, a target with a Pentium 4 baseline. We typically use i586 to indicate "older than i686" (with i686 meaning "Pentium 4"), so there is a direct conflict here between the vendor convention and our own convention, which will easily be confusing for Rust users.

[apiraino]

For QNX Neutrino 7.0.0, that is the name that Blackberry QNX use for their C toolchain:

~/qnx700/host/darwin/x86_64/usr/bin/i586-pc-nto-qnx7.0.0-ld

I think the primary question you all need to ask yourselves is:

* Is it better for targets to be internally consistent (i.e. within `rustc`), or is it better for each target be consistent with other toolchains for that target

@jonathanpallant it seems that @flba-eb suggests that i586-pc-nto-qnx700 could be a "good enough" candidate. Am I reading correctly that you don't have a different opinion or alternate suggestions?

[RalfJung]

To be clear the new name would be i686-pc-nto-qnx700; that would be consistent with out other i*86 targets.

[jonathanpallant]

It was merged before I had a chance to comment (unlike the PR that added it, which I recall took months to approve and merge). But yes, I have always said Rust should prioritise internal consistency over external; this change does that and I support it.

[RalfJung]

Ah, I hadn't even seen #137324, nice. :)

That makes i386-apple-ios the only remaining culprit. The vibes given by @madsmtm were that this target will anyway be removed. Is there a timeline for that?

[madsmtm]

That makes i386-apple-ios the only remaining culprit. The vibes given by @madsmtm were that this target will anyway be removed. Is there a timeline for that?

Not really a timeline for it, no. If it's important to you, I'd be fine with renaming the target in the meantime (if so, it should be renamed to i686-apple-ios-sim).

[RalfJung]

Not very important, no.

[apiraino]

Last question about target names should be addressed in comment (iiuc)

Comment also provides a rename suggestion for i386-apple-ios.

@rustbot label -I-compiler-nominated