linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Christian Schrefl <chrisi.schrefl@gmail.com>,
	 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	 Jocelyn Falempe <jfalempe@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	 rust-for-linux <rust-for-linux@vger.kernel.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 dri-devel <dri-devel@lists.freedesktop.org>,
	 Linus Walleij <linus.walleij@linaro.org>
Subject: Re: `u64` by `u64` div/mod in DRM QR for arm32
Date: Mon, 5 May 2025 09:37:31 +0200 (CEST)	[thread overview]
Message-ID: <5bcf120e-72a4-fd2e-c70a-3cd34d04fc88@linux-m68k.org> (raw)
In-Reply-To: <Z_1mEHnzYjhz0Ldz@shell.armlinux.org.uk>

 	Hi Russell,

On Mon, 14 Apr 2025, Russell King (Oracle) wrote:
> On Mon, Apr 14, 2025 at 09:21:42PM +0200, Christian Schrefl wrote:
>> Hi Miguel,
>>
>> On 14.04.25 8:14 PM, Miguel Ojeda wrote:
>>> Hi Jocelyn, Christian,
>>>
>>> I started build-testing arm 32-bit within my other usual routine
>>> tests, and I hit:
>>>
>>>     ld.lld: error: undefined symbol: __aeabi_uldivmod
>>>    >>> referenced by drm_panic_qr.rs:417 (drivers/gpu/drm/drm_panic_qr.rs:417)
>>>    >>> drivers/gpu/drm/drm_panic_qr.o:(<drm_panic_qr::SegmentIterator
>>> as core::iter::traits::iterator::Iterator>::next) in archive vmlinux.a
>>>
>>> which comes from both these `u64` by `u64`:
>>>
>>>     let out = (self.carry / pow) as u16;
>>>     self.carry = self.carry % pow;
>>>
>>> Christian: I guess we can offer a set of `div64` functions using the C
>>> ones, at least for the time being, and eventually wire the actual
>>> operator with some support from upstream Rust. Or do you have
>>> something else in mind? (i.e. I think you have been discussing
>>> intrinsics lately)
>>
>> I think using the C implementations is fine. Not sure how much the
>> FFI is going to matter for performance, but it should be rare enough
>> that is shouldn't matter (and hopefully we will get cross lang LTO
>> or something similar at some point).
>>
>> We could also just implement the intrinsic(s) ourselves, but then
>> the u64 divisions would be implicit which is probably undesired.
>> We could also rename the intrinsics so they are only usable from
>> specific crates.
>>
>> I think we need the opinion of the some arm people here.
>>
>> CC Russell King and Linus Walleij.
>
> The kernel has had the general position that u64 by u64 division is
> silly and isn't supported. Several 32-bit architectures including

s/isn't supported/isn't supported implicitly/

> 32-bit ARM don't support it.

It is supported when called explicitly through div64_u64()
https://elixir.bootlin.com/linux/v6.14.5/source/include/linux/math64.h#L60
But you better think twice before using it, especially in
performance-critical code.

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds


  parent reply	other threads:[~2025-05-05  7:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-14 18:14 `u64` by `u64` div/mod in DRM QR for arm32 Miguel Ojeda
2025-04-14 19:21 ` Christian Schrefl
2025-04-14 19:46   ` Russell King (Oracle)
2025-04-15  9:14     ` Jocelyn Falempe
2025-04-15 12:50       ` Paolo Bonzini
2025-05-05  7:37     ` Geert Uytterhoeven [this message]
2025-04-14 20:04 ` Miguel Ojeda

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=5bcf120e-72a4-fd2e-c70a-3cd34d04fc88@linux-m68k.org \
    --to=geert@linux-m68k.org \
    --cc=arnd@arndb.de \
    --cc=chrisi.schrefl@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jfalempe@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    /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).