Skip to content

lower baseline for i686 on unixlike targets #100969

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

goshhhy
Copy link

@goshhhy goshhhy commented Aug 24, 2022

experimental, draft PR for rust-lang/compiler-team#548

this commit lowers the baseline for i686 from 'pentium4' to 'pentiumpro'
on the following targets to match their expected baseline for i686:

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

the pentium4 is not i686-class, and setting it as baseline results
in Rust using SSE2, which i686-class processors never had. this
change enables users of these platforms, with their expected
baseline, to use the upstream Rust host tools, and binaries built
for their platform. I fall into this category of users.

at least Debian and Gentoo have issues relating to this, and at least
Debian and FreeBSD patch Rust in order to make a similar change and
enable Rust to work correctly on their expected baseline. Users with
i686 hardware running distributions that do not distribute their own
modified toolchain are left unable to use Rust or software written
in it. as an aside, Rust is now a de-facto requirement to have a usable
GNU/Linux installation with a GUI.

Rust has an existing issue #82435, which this patch
resolves; this patch also obviates the need for the MCP i filed as
rust-lang/compiler-team#543.

NetBSD (and i believe OpenBSD) normally targets i486 where possible,
and i586 where atomics make that difficult (which includes all Rust
programs); if targeting i686, these operating systems would also
expect a lower baseline than pentium4.

Haiku normally targets i586, but would also expect a lower baseline
than pentium4 for an i686 target.

Distributions such as Fedora which do not have a 32-bit version and
only use i686 for multilib can easily alter their build system to
enable SSE2, to match their expected baseline of x86_64 processors
running in 32-bit compatibility mode (all of which have SSE2).
@cuviper has expressed willingness to make this patch in Fedora.

Targets not changed are left as-is for the following reasons:

  • Rust supports no earlier than Windows 7; Windows 7 and later all
    require SSE2, and so a minimum of Pentium 4 or similar.
  • UEFI was not introduced until 2004 and not common until ~2011,
    well after the Pentium 4's heyday, and does not self-host
  • I am aware of no scenario under which VxWorks would be running
    on a 32-bit x86 processor with a lower featureset than pentium4,
    unless it is a Vortex86, which is i586-class. even then, these
    would not be compiling programs for themselves, and the party
    building programs for that platform would have the ability to
    set target flags that make sense for their situation.

this commit lowers the baseline for i686 from 'pentium4' to 'pentiumpro'
on the following targets to match their expected baseline for i686:

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

the pentium4 is not i686-class, and setting it as baseline results
in Rust using SSE2, which i686-class processors never had. this
change enables users of these platforms, with their expected
baseline, to use the upstream Rust host tools, and binaries built
for their platform. I fall into this category of users.

at least Debian and Gentoo have issues relating to this, and at least
Debian and FreeBSD patch Rust in order to make a similar change and
enable Rust to work correctly on their expected baseline. Users with
i686 hardware running distributions that do not distribute their own
modified toolchain are left unable to use Rust or software written
in it. as an aside, Rust is now a de-facto requirement to have a usable
GNU/Linux installation with a GUI.

Rust has an existing issue rust-lang#82435, which this patch
resolves; this patch also obviates the need for the MCP i filed as
rust-lang/compiler-team#543.

NetBSD (and i believe OpenBSD) normally targets i486 where possible,
and i586 where atomics make that difficult (which includes all Rust
programs); if targeting i686, these operating systems would also
expect a lower baseline than pentium4.

Haiku normally targets i586, but would also expect a lower baseline
than pentium4 for an i686 target.

Distributions such as Fedora which do not have a 32-bit version and
only use i686 for multilib can easily alter their build system to
enable SSE2, to match their expected baseline of x86_64 processors
running in 32-bit compatibility mode (all of which have SSE2).
@cuviper has expressed willingness to make this patch in Fedora.

Targets not changed are left as-is for the following reasons:

- Rust supports no earlier than Windows 7; Windows 7 and later all
  require SSE2, and so a minimum of Pentium 4 or similar.
- UEFI was not introduced until 2004 and not common until ~2011,
  well after the Pentium 4's heyday.
- I am aware of no scenario under which VxWorks would be running
  on a 32-bit x86 processor with a lower featureset than pentium4,
  unless it is a Vortex86, which is i586-class. even then, these
  would not be compiling programs for themselves, and the party
  building programs for that platform would have the ability to
  set target flags that make sense for their situation.
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 24, 2022
@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive
Copy link
Contributor

⚠️ Warning ⚠️

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 24, 2022
@jackh726
Copy link
Member

Going to mark this as blocked on rust-lang/compiler-team#548 (needs a second)

@jackh726 jackh726 added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 26, 2022
@Dylan-DPC
Copy link
Member

Unblocking this because rust-lang/compiler-team#548 was closed because rust-lang/compiler-team#543 superseded it.

@Dylan-DPC Dylan-DPC added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels May 16, 2023
@Dylan-DPC
Copy link
Member

@goshhhy any updates on this?

@nikic
Copy link
Contributor

nikic commented Jul 25, 2023

This has been superseded by #108716, so I'm closing this PR.

@nikic nikic closed this Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants