AVX option leaking into common part makes drivers to crash on non-AVX CPUs

System information

• OS: CentOS Linux
• GPU: 01:03.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] ES1000 [1002:515e] (rev 02)
• Kernel version: 3.10.0-957.5.1.el7.x86_64
• Mesa version: 20.2.0 and 20.3.0-rc1
• Desktop manager and compositor: Gnome3, but also using Xvfb

Describe the issue

Compiling Mesa version 20.2.0 I noticed it was crashing on an old system with brand new CentOS7 installation. The system is lacking on AVX instructions at all. This was working on 17.1.10.

The crash is because of an Illegal Instruction: vzeroupper (belonging to AVX).

I tried GCC 9.2.0 and GCC 7.3.0 and the issue persists.

Setting optimizations=0 in meson arguments seems to clear the issue. optimizations=1 makes it to appear. As the backtrace shows, Mesa seems to leverage something in LLVM indirectly. But using the same LLVM build, with different optimizations in Mesa turn the issue on or off.

I tested LLVM from version 7 through 10, but the issue appears with all of them.

Regression

Using Mesa 17.1.10 was working.

Log files as attachment

Backtrace with release mode:

Program received signal SIGILL, Illegal instruction.
0x00007ffff5fd4028 in GlobalKnobs::GlobalKnobs() () from /SCRATCH/mesa_src/lib64/libGL.so.1
(gdb) bt
#0  0x00007ffff5fd4028 in GlobalKnobs::GlobalKnobs() () from /SCRATCH/mesa_src/lib64/libGL.so.1
#1  0x00007ffff58455c9 in _GLOBAL__sub_I_gen_knobs.cpp () from /SCRATCH/mesa_src/lib64/libGL.so.1
#2  0x00007ffff7dea4c3 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7ddc1aa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#4  0x0000000000000001 in ?? ()
#5  0x00007fffffffde68 in ?? ()
#6  0x0000000000000000 in ?? ()

Backtrace with debug build of llvm 7.0.0 and a debug build with optimizations in Mesa:

Program received signal SIGILL, Illegal instruction.
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_realloc_insert<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&> (this=0x6209d0, __position=..., __args#0=...) at /SCRATCH/GCC/include/c++/9.2.0/bits/char_traits.h:365
365             return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
(gdb) bt
#0  std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_realloc_insert<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&> (this=0x6209d0, __position=..., __args#0=...) at /SCRATCH/GCC/include/c++/9.2.0/bits/char_traits.h:365
#1  0x00007ffff4a399f6 in std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::push_back (this=0x6209d0, __x=...)
    at /SCRATCH/GCC/include/c++/9.2.0/bits/stl_vector.h:1195
#2  0x00007ffff4a3865b in llvm::UniqueVector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::insert (this=0x6209a0, Entry=...) at /SCRATCH/mesa_src/llvm-project/llvm/include/llvm/ADT/UniqueVector.h:52
#3  0x00007ffff4a380f7 in llvm::DebugCounter::addCounter (this=0x620980, Name=..., Desc=...) at /SCRATCH/mesa_src/llvm-project/llvm/include/llvm/Support/DebugCounter.h:161
#4  0x00007ffff4a37ead in llvm::DebugCounter::registerCounter (Name=..., Desc=...) at /SCRATCH/mesa_src/llvm-project/llvm/include/llvm/Support/DebugCounter.h:70
#5  0x00007ffff4cdee9a in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /SCRATCH/mesa_src/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:74
#6  0x00007ffff4cdf21f in _GLOBAL__sub_I_EarlyCSE.cpp(void) () at /SCRATCH/mesa_src/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:1329
#7  0x00007ffff7dea4c3 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#8  0x00007ffff7ddc1aa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffde68 in ?? ()
#11 0x0000000000000000 in ?? ()
(gdb) 

This was disccused in !6565 (merged). It was reproduced by @jzielins.