x86_64: check OSXSAVE+XCR0 for AVX, read BMI1/AVX2 from EBX - #198

What

Fixes two bugs in MacroAssemblerX86_64::collectCPUFeatures() on Linux/Windows that cause the JIT to emit VEX-encoded (AVX) instructions on machines where AVX is not actually usable.

1. AVX detection missing OSXSAVE / XCR0 check

The non-Darwin path decided AVX was available based on CPUID.1:ECX[28] alone:

s_avxCheckState = (cpuid[2] & (1 << 28)) ? CPUIDCheckState::Set : CPUIDCheckState::Clear;

Per the Intel SDM, software must verify three things before executing AVX:

1. CPUID.1:ECX.AVX[28] = 1 — CPU supports AVX
2. CPUID.1:ECX.OSXSAVE[27] = 1 — OS has enabled XGETBV
3. XCR0[2:1] = 11b — OS saves XMM and YMM state on context switch

Checking only (1) is insufficient. Under many hypervisors (Xen, Hyper-V, older KVM configs, cloud VMs without AVX passthrough), ECX[28] is passed through from the physical CPU while the guest kernel has not enabled XSAVE/YMM state. Every VEX-encoded instruction then raises #UD → SIGILL.

Every if (supportsAVX()) guard in MacroAssemblerX86_64.h (~80 sites), MacroAssembler::probe(), isX86_64_AVX() → Options::useWasmSIMD(), and the Yarr JIT all sit downstream of this — so a false positive here means the JIT emits VEX everywhere and crashes when the code runs.

This is the cause of the "baseline build SIGILL in JIT code" class of Bun crash reports on VMs:

• Probabilistic SIGILL crash on no-AVX CPU with deep async recursion (baseline build) bun#27844 (Xeon Gold in a hypervisor with AVX masked — probabilistic SIGILL once DFG compiles deep async recursion)
• Bun 1.3.11 crashes with Illegal instruction in Xen guest during JSC startup bun#28723 (Xen guest — SIGILL at JSC startup)
• Crash on Windows x64 (no AVX/AVX2) — "attempt to use null value" panic in v1.3.11 bun#28399 (Windows Server 2019 VM without AVX passthrough)

Bun's own bun_cpu_features() uses __builtin_cpu_supports("avx") / IsProcessorFeaturePresent(PF_AVX_INSTRUCTIONS_AVAILABLE), both of which do perform the full OSXSAVE/XCR0 check — which is why Bun's crash reporter correctly prints no_avx while JSC's JIT simultaneously believes AVX is available.

Fix: require ECX[27] (OSXSAVE), then XGETBV(0) and check (XCR0 & 0x6) == 0x6 before setting s_avxCheckState. Same approach as simdutf (Source/WTF/wtf/simdutf/simdutf_impl.h:1029-1038), compiler-rt, and every other correct AVX detector.

2. BMI1 / AVX2 read from wrong CPUID register

CPUID cpuid = getCPUID(0x7);
s_bmi1CheckState = (cpuid[2] & (1 << 3)) ? ... ;  // ECX[3] is PKU, not BMI1
s_avx2CheckState = (cpuid[2] & (1 << 5)) ? ... ;  // ECX[5] is WAITPKG, not AVX2

getCPUIDEx returns [EAX, EBX, ECX, EDX]. For leaf 7 sub-leaf 0, BMI1 is EBX[3] and AVX2 is EBX[5]. The code was reading cpuid[2] (ECX) — so supportsBMI1() actually reported PKU and supportsAVX2() reported WAITPKG. On most modern Intel server CPUs this mis-reports AVX2 as unavailable (verified: Xeon Platinum 8375C has EBX[5]=1 but ECX[5]=0).

Fix: read cpuid[1] (EBX). Also gate AVX2 on the AVX result since AVX2 is VEX-encoded and requires the same OS YMM state.

Scope

Linux and Windows only (#if !OS(DARWIN) branches). Darwin is unchanged — it hardcodes s_avxCheckState = Set and uses sysctlbyname for BMI1/AVX2, which is correct since every x86-64 Mac has AVX and macOS always enables it. There is no darwin-x64-baseline Bun build.

The same code exists in upstream WebKit main — this is not a fork regression; probably worth upstreaming.