Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[Paul Gevers]

Control: severity -1 important

Hi,

We discussed this during the Release Team IRC meeting [1], and we 
decided that it's too late in the release cycle to fix this. We'll 
accept the de-facto baseline bump for bookworm and document the fact in 
the Release Notes.


Having said that, without having discussed it, I don't think we object 
having support for the previous baseline in trixie, if we still release 
i386 with it.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[James Addison]

Followup-For: Bug #973414
X-Debbugs-Cc: fierel...@gmail.com

On Mon, 3 Apr 2023 23:07:35 +0200, Fierelier wrote:
> * In terms of confusion: I think using the Rust i586 toolchain, and
> building for i586 with Rust might be less confusing, because altering
> the i686 definitions for rustc will make it act differently compared
> to other platforms. People could compile code for i686 on Debian, get
> working code, but then if someone else does the same on another
> distro, the produced binary would not work on the same devices.

That's a fair point, yep; matching upstream behaviour is often the simplest and
most understandable approach.

It seems the choice is between using an upstream-compatible definition, or an
inter-toolchain-compatible definition (are there any other choices?  I did
notice use of per-extension feature flags in some build configurations. they
don't appear widely standardized though, or at least that's my initial sense).

> Although, I think changing the i686 definition down, like you did, is
> the most accurate way to achieve the goal, and is what I personally
> think should be mainline. If the accurate definition proves itself on
> Debian, it might find itself in mainline Rust, too, which would be
> awesome.

Thanks - and thank you for re-stating the intent of the patch. (I confusingly
wrote "my personal preference" instead of "my personal opinion" in a previous
comment)

I wouldn't want Debian's choice to be intended as a way to influence Rust's
upstream choices.  It'd be more a case of "who is comfortable using a divergent
definition of "i686" for longer before their respective communities call them
out on it" (in other words: each project can take their own path, and each
project can decide how to proceed, as they usually would).

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[Fierelier OwO]

* In terms of efficiency: I believe that if people are on the hunt for
efficiency on CPUs at the top-end of x86, they shall use distros that
target Pentium 4 explicitly. There are a few of them out there, now.
Archlinux32 for example carries packages for i486, i686 and Pentium 4
where possible, and lets you enable the architectures that suit you
best.

* In terms of confusion: I think using the Rust i586 toolchain, and
building for i586 with Rust might be less confusing, because altering
the i686 definitions for rustc will make it act differently compared
to other platforms. People could compile code for i686 on Debian, get
working code, but then if someone else does the same on another
distro, the produced binary would not work on the same devices.

Although, I think changing the i686 definition down, like you did, is
the most accurate way to achieve the goal, and is what I personally
think should be mainline. If the accurate definition proves itself on
Debian, it might find itself in mainline Rust, too, which would be
awesome.

Thank you for your continued interest in this topic.

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[James Addison]

Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: fierel...@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