Re: [RFC PATCH 04/20] compiler_types.h: Don't instrument __always_inline functions for coverage

["Chuck Wolber" <chuck@wolber.net>]

On Wed, Oct 28, 2026, at 4:45 PM, Sasha Levin wrote:
> On Wed, Oct 28, 2026 at 02:51:40PM +0100, Peter Zijlstra wrote:
>>This is pretty vile. But also, since people were trying to use MC/DC
>>for validation efforts and the like, how does this impact them? If I
>>understand correctly their previous emails on the topic, this means
>>they have to go manually audit every single __always_inline function.
>
> Yes, the __always_inline helpers join noinstr code as something that
> has to be justified separately rather than covered by tests. Steve's
> answer to your noinstr question in 2024 [1] was that this is workable
> as long as the number of distinct categories stays small, and this
> adds one (556 functions and 445 MC/DC conditions for the config in the
> changelog).
>
> Chuck, Steve, does that match what you'd expect on your side?

Yes, this is correct.

And "small" is a relative term that should not be a factor that holds
back this patchset. Perfect is the enemy of good and we can always
improve on the level of coverage over time.


>>Still, I'm left wondering if these tools should be fixed. For
>>instance, while the front-end emits this instrumentation, the backend
>>could easily remove it again when it finds itself in the context of a
>>noinstr function after inlining.
>
> Yup, we should do that. Both GCC and Clang add the counters before
> inlining and let always_inline win over the attribute mismatch, so
> neither can do it today. We can look at improving them, but it's
> probably outside of what this series can do.

Agreed. This is a good example of how the level of coverage can be
improved.


..Ch:W..