Re: [PATCH 03/12] x86: Add cpu_vendor() as a wrapper for the host's CPU vendor

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.02.2026 17:15, Alejandro Vallejo wrote:
> Introduces various optimisations that rely on constant folding, Value
> Range Propagation (VRP), and Dead Code Elimination (DCE) to aggressively
> eliminate code surrounding the uses of the function.
> 
>   * For single-vendor+no-unknown-vendor builds returns a compile-time
>     constant.
>   * For all other cases it ANDs the result with the mask of compiled
>     vendors, with the effect of performing DCE in switch cases, removing
>     dead conditionals, etc.
> 
> It's difficult to reason about codegen in general in a project this big,
> but in this case the ANDed constant combines with the values typically
> checked against, folding into a comparison against zero. Thus, it's better
> for codegen to AND its result with the desired compared-against vendor,
> rather than using (in)equality operators. That way the comparison is
> always against zero.
> 
>   "cpu_vendor() & (X86_VENDOR_AMD | X86_VENDOR_HYGON)"
> 
> turns into (cpu_vendor() & X86_VENDOR_AMD) in AMD-only builds (AND +
> cmp with zero). Whereas this...
> 
>   "cpu_vendor() == X86_VENDOR_AMD"
> 
> forces cpu_vendor() to be ANDed and then compared to a non-zero value.

Coming back to this: How does the value compared against being zero or
non-zero matter here? As long as cpu_vendor() yields a compile-time
constant, the compiler should be able to leverage that for DCE? And
even if it's not a compile time constant, bits masked off in principle
allow the compiler to leverage that, too. It may of course be that
even up-to-date compilers fall short of doing so.

Jan