[PATCH RFC v2 5/5] lib/Kconfig.debug: introduce CONFIG_NO_AUTO_INLINE
Chen Linxuan
me at black-desk.cn
Fri Apr 18 03:24:53 PDT 2025
On 4/17/25 5:04 PM, Bart Van Assche wrote:
> On 4/16/25 2:44 AM, Chen Linxuan via B4 Relay wrote:
> > 2. Make it depends on X86 and LOONGARCH,
> > as I haven't test other architectures
>
> That sounds weird to me. Shouldn't this option be made architecture-
> independent?
It should, but I have only tested it on X86 and LOONGARCH.
>
> > +config NO_AUTO_INLINE
> > + bool "Disable compiler auto-inline optimizations (EXPERIMENTAL)"
> > + default n
> > + depends on CC_IS_GCC && (X86 || LOONGARCH)
>
> Why "depends on CC_IS_GCC"? Please make sure that both gcc and clang are
> supported.
I make it depends on CC_IS_GCC because
1. Clang do not have `-fno-inline-small-functions`
and `-fno-inline-functions-called-once`.
2. If we wrap those options with cc-option,
Clang 18.1.3 fails to compile test_bitmap_const_eval(),
with config KASAN and TEST_BITMAP is enabled.
Comments above test_bitmap_const_eval() says that:
> /*
> * FIXME: Clang breaks compile-time evaluations when KASAN and GCOV are enabled.
> * To workaround it, GCOV is force-disabled in Makefile for this configuration.
> */
It seems there are some issues with Clang's compile-time evaluations.
So I think there are some ways to workaround this problem:
1. Make NO_AUTO_INLINE depends on CC_IS_GCC;
2. Make NO_AUTO_INLINE depends on KASAN=n;
3. Disable NO_AUTO_INLINE for TEST_BITMAP
like how we handle CC_IS_CLANG && KASAN && GCOV in lib/Makefile:
> ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_KASAN),yy)
> # FIXME: Clang breaks test_bitmap_const_eval when KASAN and GCOV are enabled
> GCOV_PROFILE_test_bitmap.o := n
> endif
Which one do you prefer or do you have any other suggestions?
>
> Thanks,
>
> Bart.
More information about the Linux-nvme
mailing list