Re: [PATCH] mm: optimize the implementation of WARN_ON_ONCE_GFP()

[Andrew Morton]

On Tue, 10 Mar 2026 14:52:31 +0000 David Laight <david.laight.linux@xxxxxxxxx> wrote:

> > > If a and b is both unlikely, then "unlikely(a) && unlikely(b)" will
> > > generate better code than "unlikely(a && b)". This is also true for gcc.  
> > 
> > What are the details of how it's better for gcc?
> 
> I'm not sure about that specific case, but I've definitely seen gcc
> generate sub-optimal code for some un/likely() of compound expressions.
> The underlying cause is that the code is (probably) first transformed to:
> 	bool tmp = expression;
> 	if (unlikely(tmp)) ...
> this means that you lose some of the short-circuiting that happens
> early in the code generation of 'if (expression)'.
> 
> It is also not at all clear what you want the compiler to generate.
> For 'unlikely(a || b)' you want 'if (a) goto x; if (b) goto x' so that
> the 'likely' path is the no-branch one.
> But for 'unlikely(a && b)' you still want 'if (a) goto x; y:' which means
> that the 'b' test is out-of-line and has to be 'x: if (!b) goto y' to
> avoid a branch when a is false - but that means you have a 'normally
> taken' branch after the test of b.
> That pretty much means the compiler has to decide which unlikely()
> to ignore.
> So it only makes sense to do 'if (unlikely(a) && b)'.
> Indeed even 'if (unlikely(a) && likely(b))' may be better!

fwiw, this change makes no change to `size mm/page_alloc.o' for x86_64
gcc defconfig.

Given the expressed objections and that WARN_ON_ONCE_GFP() is used only
twice in the whole kernel, I think I'll remove this patch.

Xie, if you disagree with this then please resubmit the patch with a
more convincing justification and hopefully people will reconsider it.

Thanks.