From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
linux-sparse@vger.kernel.org, linux-xfs@vger.kernel.org,
smatch@vger.kernel.org
Subject: Re: sparse feature request: nocast integer types
Date: Mon, 27 Nov 2023 09:26:03 -0800 [thread overview]
Message-ID: <CAHk-=whC6fX5U3kfG9zKxw+_G=n=Y0VJYZ-BBF7EQ1KZM2Zb2g@mail.gmail.com> (raw)
In-Reply-To: <ZWS+LLCggp70Eav3@infradead.org>
On Mon, 27 Nov 2023 at 08:50, Christoph Hellwig <hch@infradead.org> wrote:
>
> Yes, doing it without specific annotations seems like a pain. I did a
> little prototype with the existing sparse __nocast for one xfs type that
> is not very heavily used, and it actually worked pretty good.
>
> The major painpoint is that 0 isn't treated special, but with that
> fixed the amount of churn is mangable.
I would suggest trying to just treat "__bitwise" as the "nocast" type.
And note that doing a
typedef uXX __bitwise new_integer_type;
will make a *specific* new integer type that is only compatible with
itself (so not other bitwise types).
Of course, that only works if you are then willing to just use
accessor functions when you actually want to do arithmetic on the
values. If you use a *lot* of arithmetic - as opposed to just passing
values around - it is too painful.
> The next big thing is our stupid 64-bit divison helpers (do_div & co),
> which require helpers to do that case. I'm actually kinda tempted to
> propose that we drop 32-bit support for xfs to get rid of that and a
> lot of other ugly things because of do_div. That is unless we can
> finally agree that the libgcc division helpes might not be great but
> good enough that we don't want to inflict do_div on folks unless they
> want to optize that case, which would be even better.
>
> Linus, any commens on that?
Some architectures do that, but honestly, we've had *horrendous*
numbers of cases where people did 64x64 divisions without ever
realizing what they did. Having it cause compile failures on x86 -
even if it silently works elsewhere - means that they do get caught
fairly quickly.
Just go to lore, and search for "__divdi3". You will find *tons* of
kernel test robot reports for completely idiotic cases that then never
get to me because of this.
IOW, you may not see it in the resulting kernel, but the reason you
don't see it is *exactly* because we require that do_div() dance for
64-bit divides.
The least one I see is literally from less than a week ago, when media
code tried to do this:
i = v / (1LL << fraction_bits);
without realizing that a signed 64-bit division is truly *horrendous* here.
So you may never see this, but it's a *constant* churn, and we really
are better for it. It's not some historical artifact, it's a "the
kernel test robot finds stuff weekly".
Linus
prev parent reply other threads:[~2023-11-27 17:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ZUxoJh7NlWw+uBlt@infradead.org>
2023-11-27 12:51 ` sparse feature request: nocast integer types Dan Carpenter
2023-11-27 16:05 ` Christoph Hellwig
2023-11-27 17:26 ` 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-=whC6fX5U3kfG9zKxw+_G=n=Y0VJYZ-BBF7EQ1KZM2Zb2g@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=dan.carpenter@linaro.org \
--cc=hch@infradead.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=smatch@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 read-only IMAP folder(s) and NNTP newsgroup(s).