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
