In the summer of 2020, AMD, Intel, Red Hat, and SUSE collaborated to define three x86-64 microarchitecture levels on top of the x86-64 baseline.

GCC and glibc disagree on the definition of feature sets, and the glibc selection mechanism is vendor-specific. Until recently, there has been little guidance on what CPU features to assume in optimized libraries. The plethora of choices poses a problem not only for the dynamic linker but also for programmers. We see this especially on the x86 architecture, where many optional features have been added over the years (see the Wikipedia article for the CPUID instruction for a list). However, the power-set construction involved in the library lookup mechanism poorly matches current platforms with a long list of optional CPU features. Originally, this mechanism was designed to support perhaps one or two alternative library implementations, in addition to the default (fallback) implementation that is usually installed in the /usr/lib64 directory. The GNU C Library (glibc) offers a way to load optimized libraries that use additional hardware features that might not be present on all systems. Background of the x86-64 microarchitecture levels In this article, I discuss a new approach to building the x86-64 variant of Red Hat Enterprise Linux (RHEL) 9 and share Red Hat's recommendation for that build. Programs that use newer CPU instructions might not run on older CPUs. The distribution's default compiler flags are significant for hardware-platform compatibility. One of the most important early decisions when building a Linux distribution is the scope of supported hardware.

Rhel latest release