linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "Matthew Auld" <matthew.auld@intel.com>,
	"Arunpravin Paneer Selvam" <Arunpravin.PaneerSelvam@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: Linux 6.8-rc5
Date: Tue, 20 Feb 2024 14:02:19 -0800	[thread overview]
Message-ID: <CAHk-=wgaaFFoc12yqoQVcQEHN4rYTxTzd7uKgFG6Y0XzJbxpAA@mail.gmail.com> (raw)
In-Reply-To: <2374eaeb-fa34-44b9-a945-2cd871aacf7b@roeck-us.net>

On Tue, 20 Feb 2024 at 13:48, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Turns out it wasn't this code, but
>
> > Now, the __moddi3() is a *bit* more reasonable, because I assume it comes from
> >
> >                  int slot = i % 3;
>
> this code.

Yeah. It's still the kernel doing silly things for no good reason, but
a compiler can certainly do a small-constant 64-bit unsigned division
without actually going to the expense of actually doing a full divide.

For example, in this case, because 1**32 mod 3 is 1, you can literally
just add the high bits together with the low bits (with carry), and do
a 32-bit modulus.

And in fact, you can then turn that 32-bit modulus into a multiply
instead, avoiding doing any expensive divide at all.

And gcc knows to do all this. I *suspect* that the failing
architectures end up not having a 32x32->64 multiply, or maybe they
just don't have a very good machine description, and that's why gcc
failed on them and just ended up doing the stupid thing.

Regardless, our kernel code was just not good.  It should be fixed now.

           Linus

      reply	other threads:[~2024-02-20 22:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-18 21:13 Linux 6.8-rc5 Linus Torvalds
2024-02-19  8:07 ` Build regressions/improvements in v6.8-rc5 Geert Uytterhoeven
2024-02-19  9:54   ` Geert Uytterhoeven
2024-02-19  8:12 ` Geert Uytterhoeven
2024-02-20 19:08 ` Linux 6.8-rc5 Guenter Roeck
2024-02-20 19:57   ` Linus Torvalds
2024-02-20 20:16     ` Linus Torvalds
2024-02-20 23:07       ` Shuah Khan
2024-02-20 20:37     ` Linus Torvalds
2024-02-20 20:51     ` Geert Uytterhoeven
2024-02-20 21:48     ` Guenter Roeck
2024-02-20 22:02       ` Linus Torvalds [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wgaaFFoc12yqoQVcQEHN4rYTxTzd7uKgFG6Y0XzJbxpAA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=Arunpravin.PaneerSelvam@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=matthew.auld@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).