[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