Re: [PATCH v2] rust: sync: optimize rust symbol generation for CondVar

[Kunwu Chan]

On 2025/3/25 18:12, Miguel Ojeda wrote:
> On Tue, Mar 25, 2025 at 4:02 AM Kunwu Chan <kunwu.chan@xxxxxxxxx> wrote:
> > Thanks for the kind reminder, I'll follow this next time
> You're welcome!
>
> > Now, the default '-Copt-level' is 2 when define
> > 'CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE',
> > and in  KBUILD_RUSTFLAGS the  '-Ccodegen-units' is 1.
> >
> > So if the config not change, the result should be the same.
> I don't think that is true, because there are a few `rustc` versions
> as well as LLVM ones that we support, so how inlining happens (at both
> `rustc` and LLVM levels) may change even if the configuration is
> essentially the same.
>
> And, of course, then there are other non-compiler-related kernel
> config options (i.e. not compiler flags, but other stuff, like `cfg`s)
> that influence which and how gets emitted and thus the inlining
> decisions.
> Eventually we should have pure GCC builds too, which is yet another factor...
>
> To be clear, I agree with Boqun that having to write `#[inline]`
> everywhere is not great. Rust 1.75 already started to tag small
> functions as `#[inline]` to try to prevent the proliferation of the
> attribute, which is good (i.e. which is what triggered the message in
> Compiler Explorer).

Thanks for the detailed reply.

Sure on the one hand, the decisions is a result of many factors,

on the other hand the rustc and llvm is rapidly developing.

It's a complicated thing.

> By the way, one difference is whether it is `pub` -- the `notify()`
> isn't (unlike the others), but if it were, then we would have needed
> the `#[inline]`, from a quick test.
That is a easy way to judge. I learned.
> Thanks!
>
> Cheers,
> Miguel

--
Thanks,
  Kunwu.Chan(Tao.Chan)