LLVM JIT emitting vbroadcastss on a machine that doesn't support it

Hi all,
Looking into a crash on a users’ machine, I’m seeing
illegal instruction:
0000016920350000 vbroadcastss xmm0,xmm1
in a function that was emitted by my JIT compiler that uses LLVM.

Why is LLVM emitting an AVX instruction on a machine that doesn’t support it?

The (abridged) target selection code in my JIT compiler looks like:

this->triple = llvm::sys::getProcessTriple();
this->triple.append("-elf");

std::string cpu_name = (std::string)llvm::sys::getHostCPUName();

if(cpu_name == "generic" || cpu_name == "x86-64") // If LLVM can't detect it, it's probably something pretty new, so just consider it >= to a corei7 in terms of capabilities.
	cpu_name = "corei7";

this->target_machine = engine_builder.selectTarget(
	llvm::Triple(this->triple), // target triple
	"",  // march
	cpu_name, // mcpu - e.g. "corei7", "core-avx2"
	mattr);

Edit: view code on github here: https://github.com/glaretechnologies/winter/blob/78eb7a531ee4b41b5893f9e4ed368e4b3f3ce2b9/VirtualMachine.cpp#L870

It’s possible the cpu_name is being set to corei7, it’s not easy for me to tell since this happened on another users’ computer.

Nevertheless, the first generation of i7s (nehalem) didn’t support AVX right?
So presumably no AVX should be generated even if cpu_name is being set to corei7.

LLVM version used is 15.0.7.

I’m not an expert in LLVM’s JIT but I think you can add “-avx” into mattr to disable the codegen of AVX instructions.

Hi, yes I have done that as a workaround.
However this still seems like an issue with LLVM.

LLVM correctly classifies corei7 as “SSELevel 6” (SSE42) Compiler Explorer
I guess you may pass “avx” feature somewhere.

What is the user’s CPU and what how it is detected by llvm? What is the detected march? Also (unrelated to the crash), perhaps a better approach to the cpu detection would be to use getHostCPUFeatures to fill mattr and leave cpu_name alone. Although it won’t protect against the cases where some ISA requires OS support to function properly (but neither does the current code).