Package: rustc Followup-For: Bug #973414 X-Debbugs-Cc: [email protected] Hi Fierelier - thanks for your previous comment, here's my reply, slightly later than I'd hoped:
On Wed, 29 Mar 2023 00:10:52 +0200, Fierelier wrote: > - issue 1: i386, i486, i586, i686 are considered as Pentium 4 in LLVM, > which might be relevant if Rust is compiled with it: > https://github.com/llvm/llvm-project/issues/61347 Yep, this is relevant. Debian does currently use LLVM for rustc builds, yep. Along the way I found the rustc build README.Debian[1] that's a very useful explanatory guide. To be slightly more specific, currently LLVM 14 is in use, and some of the build options for it (including that version number[2]) are placed into a config.toml[3] file that's used by the rustc build process (x.py). Included in Debian's patches for the LLVM 14 toolchain is a patch to adjust the Pentium 4 target you mention down to i686: https://sources.debian.org/src/llvm-toolchain-14/1%3A14.0.6-12/debian/patches/clang-baseline-fix-i386.patch > - issue 2: Rust considers i686 as Pentium 4, and i586 as Pentium: > https://github.com/rust-lang/rust/issues/82435 Also relevant, yep. Some of the comments, and the current title that I read for that thread ("i686 target spec disagrees with downstream definitions") discuss the core of the problem here. There are reasons for some people to want the definition of i686 to shift forward, perhaps towards the bulk of the processors within that family that are in everyday use. And there are reasons to want to keep the definition to its original, most compatible specification (although as found on my NOPL learnings, even in the early days of the P6 there was some divergence there). I don't like neither wasted CPU time, nor wasted electricity, nor wasted human time spent reading and understanding these issues, but it's difficult (for me, at least) to see a remedy that is optimal for all of those. Even writing an additional paragraph about this introduces overhead for future readers. > - When building the Rust toolchain itself, if Debian uses LLVM for it, > it might be a good idea to set the CPU target explicitly to pentiumpro > in LLVM's flags (fix issue 1) (It could also be a good idea to set > this for LLVM in general if possible, if not already done so). -- Also > compile the i586 Rust toolchain, not the i686 one (fix issue 2). It looks like that CPU target adjustment suggestion was accepted in #908561 in September Y2018. For my investigation regarding the presence of NOPL -- an instruction that is unavailable[4] on a limited number of i686 CPUs -- reducing that target further to from "pentiumpro" to "i686" appears to resolve the issue. That, I expect, also has the side-effect of omitting MMX instructions from the set of valid instructions that the Debian i386 Rust toolchain may output. So there is at least one downside there. My personal preference, that may or may not be aligned with Debian, is that switching to build from the Rust i586 toolchain, while it would be a valid fix, could cause confusion; it'd be a form of ecosystem fragmentation, and puzzling for humans in particular to reason about. Arguably that could be worthwhile puzzlement -- "why do Debian's Rust packages and libraries refer to i586?", followed by learning about the situation and knowledge spreading. Is that better than referring to i686 as with other toolchains within Debian, yet having some divergence from what upstream's i686 means? In honesty, I don't know. But I would like people who install Debian i386 on all systems within Debian's i386 baseline to be able to use those computers and the Debian-packaged software as intended, as completely as possible, and to me it feels like changing the policy baseline or changing to i586 are beyond my skills (certainly in time for bookworm), so I'm offering the best option that I can. Thanks again, James [1] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/README.Debian/#L28-L32 [2] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/rules/#L31 [3] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/config.toml.in/#L30-L43 [4] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32
