Proposal

This is a proprosal to lower the baseline expectations for the following targets from pentium4 to pentiumpro:

• i686-unknown-linux-gnu
• i686-unknown-linux-musl
• i686-unknown-freebsd
• i686-unknown-openbsd
• i686-unknown-netbsd
• i686-unknown-haiku

This is a follow-up to #543 (Promote i586-unknown-linux-gnu to Tier 2 with Host Tools). The general consensus in the Zulip discussion was that, rather than promoting that target, the i686 target baselines should be fixed such that it matches the expectation of the target operating system.

The listed targets all generally have an assumption downstream that the baseline for "i686" is a Pentium Pro, and does not include support for SSE2. There are users on these platforms (myself among them) that are unable to use Rust, or Rust binaries compiled for their platform, because Rust's baseline assumption on these targets (Pentium 4) differs from the actual expectation of the platform. This change would enable these users to use the official Rust host tools and other Rust binaries. It could cause some binaries to run slower on newer processors, if those binaries were built targeting i686.

At a minimum, Gentoo and Debian have issues about this. Rust also has an issue open on this (rust-lang/rust#82435), which this proposal would resolve. Debian and FreeBSD are known to patch the target to match their assumptions. Some other distributions ship their own compilers targeting i586 to work around this. Haiku and NetBSD both target i586 as a minimum (NetBSD targets i486 where possible; for Rust, this is currently infeasible due to atomics issues). Fedora is a notable outlier, but does not actually have i686 support - that target is used for multilib only, and all x86_64 processors support at least the featureset of the Pentium 4. If this proposal is accepted, @cuviper has expressed willingness to update Fedora such that their rustc's baseline target remains the same as it currently is (including SSE2 support). Other distributions which only offer i686 targets for multilib support on 64-bit hosts can easily follow suit.

The Windows, VxWorks and UEFI i686 targets are proposed to be left alone. Currently, the minimum supported Windows version in Rust is Windows 7, which requires a baseline of a Pentium 4 as of the March 2018 update. It is extremely unlikely that lowering the baseline for Windows would benefit any user, and extremely likely that it would negatively affect performance for many users, since 32-bit binaries are more common on 64-bit Windows than on 64-bit unix-like platforms. VxWorks is left alone as well - the purpose of this MCP is essentially to fix self-hosting for users with older hardware, and VxWorks is a target that is universally cross-compiled for. Users targeting VxWorks through cross-compilation can set target feature flags as they need. UEFI shares the same rationale, and additionally was not commonplace until nearly a decade after the release of the Pentium 4 and SSE2.

To ensure the relevant users know about this change, it was suggested that a blog post be written, similar to the one done recently for glibc and linux kernel version requirements.. I agree with this suggestion. If accepted I would also propose reaching out to some of the distribution maintainers for Rust packages, particularly for distributions that do not support 32-bit hosts, to ensure that they are aware of the change.

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.