Re: [PATCH] kbuild: rust: add AutoFDO support

[Rong Xu]

(Resend in plain-text mode)

I have reviewed this patch and it looks good to me. I suggest updating
autofdo.rst to explicitly mention support for Rust.

Regarding the naming convention, I understand Gary's point that Clang
and Rust should both be viewed as LLVM frontends. I am open to
renaming *FLAGS_AUTOFDO_CLANG to *FLAGS_AUTOFDO_LLVM. However, I would
prefer not to use *FLAGS_AUTOFDO, as GCC also supports AutoFDO, but it
hasn't been integrated into kernel builds yet.

These naming updates can be handled in a separate patch.


On Wed, Mar 25, 2026 at 5:01 PM Rong Xu <xur@xxxxxxxxxx> wrote:
>
> I have reviewed this patch and it looks good to me. I suggest updating autofdo.rst to explicitly mention support for Rust.
>
> Regarding the naming convention, I understand Gary's point that Clang and Rust should both be viewed as LLVM frontends. I am open to renaming *FLAGS_AUTOFDO_CLANG to *FLAGS_AUTOFDO_LLVM. However, I would prefer not to use *FLAGS_AUTOFDO, as GCC also supports AutoFDO, but it hasn't been integrated into kernel builds yet.
>
> These naming updates can be handled in a separate patch.
>
> Reviewed-by: Rong Xu <xur@xxxxxxxxxx>
>
>
> On Fri, Mar 20, 2026 at 9:48 PM Gary Guo <gary@xxxxxxxxxxx> wrote:
>>
>> On Thu Mar 19, 2026 at 11:54 PM GMT, Nathan Chancellor wrote:
>> > On Thu, Mar 19, 2026 at 07:09:22PM +0000, Gary Guo wrote:
>> >> On Thu Mar 19, 2026 at 4:33 PM GMT, Alice Ryhl wrote:
>> >> > On Thu, Mar 19, 2026 at 12:47 PM Gary Guo <gary@xxxxxxxxxxx> wrote:
>> >> >> On Thu Mar 19, 2026 at 11:44 AM GMT, Alice Ryhl wrote:
>> >> >> > Do you think it's worth having Rust not match the CFLAGS here?
>> >> >> >
>> >> >>
>> >> >> I think the C flags should probably be renamed AUTOFDO_LLVM too. After call, all
>> >> >> the perf tools involved here are called llvm-foobar as well.
>> >> >
>> >> > But isn't it just called this because the config option is
>> >> > CONFIG_AUTOFDO_CLANG? So it's the CFLAGS or RUSTFLAGS related to that
>> >> > particular config option. It may make sense to rename
>> >> > CONFIG_AUTOFDO_CLANG to CONFIG_AUTOFDO, but that's out-of-scope for
>> >> > this change, in my opinion.
>> >>
>> >> I get that it's an existing config name, but previously it is a correct
>> >> description, while after this change it is no longer accurate.
>> >>
>> >> I don't know if there's an established practice on renaming CONFIG options when
>> >> this sort thing happens though. Perhaps one way is to have add
>> >> CONFIG_AUTOFDO_CLANG that selects CONFIG_AUTOFDO.
>> >
>> > As Miguel mentioned, there is the transitional keyword for Kconfig to
>> > handle renames now but I would really like there to be a compelling
>> > reason for the rename other than LLVM is a little more accurate than
>> > CLANG. The kernel has never really done a great job of referring to
>> > Clang when it means the C compiler vs. the whole LLVM toolchain (like
>> > LTO_CLANG and all its derivatives should be LTO_LLVM since it requires
>> > ld.lld, llvm-nm, and llvm-ar in addition to clang). Additionally, aside
>> > from the configuration, there is the user facing Make variable
>> > CLANG_AUTOFDO_PROFILE that would presumably need to be changed for
>> > consistency.
>>
>> If you think the config name should be kept as CONFIG_AUTOFDO_CLANG, then I
>> think there is no real benefit in changing the variable name.
>>
>> Reviewed-by: Gary Guo <gary@xxxxxxxxxxx>
>>
>> Best,
>> Gary