[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250721091358.7dda6b31@nimda.home>
Date: Mon, 21 Jul 2025 09:13:58 +0300
From: Onur Özkan <work@...rozkan.dev>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Benno Lossin <lossin@...nel.org>, rust-for-linux@...r.kernel.org,
dakr@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com,
boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
a.hindborg@...nel.org, aliceryhl@...gle.com, tmgross@...ch.edu,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] rust: make various `alloc` functions `const fn`
On Sun, 20 Jul 2025 17:42:43 +0200
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:
> On Sun, Jul 20, 2025 at 5:17 PM Onur Özkan <work@...rozkan.dev> wrote:
> >
> > Personally, I don't have a specific reason. I thought the change is
> > harmless and might extend functionality for other people in the
> > future. It could also (although less likely) help the compiler
> > optimize things further.
>
> I think it is OK -- even if we promise they are `const` and we have to
> remove it in the future, it is fine, since there is no stable kernel
> API. So that flexibility is another advantage of no promises there.
>
> However, I am curious, in which cases it would help the compiler
> optimize? The compiler already has the information on whether it could
> actually be `const` and whether it can be evaluated at compile-time
> and so on -- do you mean it has an effect on heuristics like inlining
> or similar?
I thought it had effects similar to inlining, but after digging into the
assembly output of a simple program (with and without `const`
expressions) and reading some related discussions [1], it seems I was
wrong about it, sorry.
[1]: https://users.rust-lang.org/t/the-effects-of-const-fn/48303
Regards,
Onur
Powered by blists - more mailing lists