[Pkg-rust-maintainers] Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

James Addison jay at jp-hosting.net
Fri Mar 31 11:46:28 BST 2023


Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: fierelier at gmail.com

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



More information about the Pkg-rust-maintainers mailing list