Seems like Mesa will need to be updated to set all of the machine specific bits when calling into llvm.

Correct. JIT clients need to specify a CPU and/or target features.

Note that the old JIT's use of autodetection also led to frequent backend failures on newer hardware (sandy bridge and forward), as it doesn't know how to handle lots of the new instructions. That won't happen anymore.

So is it necessary to pass in everything the chip can do? So for Haswell something like "+avx, +avx2, +bmi, +bmi2, +cmov, +f16c, +fma, +movbe, +lzcnt, +popcnt, +sse, +sse2, +sse3 +ssse3, sse4.1, sse4.2" and the dozen others I forgot?
I guess I'll need to figure out how to get that from somewhere - right now we only detect some stuff for which we emit intrinsics ourselves (notably most sse versions, avx). Probably the same for the cpu model though I doubt it makes much of a difference for the generated code as nearly all of it is simd).

Seems like Mesa will need to be updated to set all of the machine specific
bits when calling into llvm.

Correct. JIT clients need to specify a CPU and/or target features.

Is there a standard way to do that through LLVM C bindings?

So is it necessary to pass in everything the chip can do? So for Haswell
something like "+avx, +avx2, +bmi, +bmi2, +cmov, +f16c, +fma, +movbe,
+lzcnt, +popcnt, +sse, +sse2, +sse3 +ssse3, sse4.1, sse4.2" and the dozen
others I forgot?

Just specify the CPU. Don't worry about the specific subtarget features.

That said, as mentioned above, unless you're using the MCJIT, you don't want to specify newer hardware, as the old JIT can't encode some of those instructions and you'll see crashes as a result.

I guess I'll need to figure out how to get that from somewhere - right now
we only detect some stuff for which we emit intrinsics ourselves (notably
most sse versions, avx). Probably the same for the cpu model though I doubt
it makes much of a difference for the generated code as nearly all of it is
simd).

llvm::sys::getHostCPUName() and llvm::sys::getHostCPUFeatures()

Seems like Mesa will need to be updated to set all of the machine specific
bits when calling into llvm.

Correct. JIT clients need to specify a CPU and/or target features.

Is there a standard way to do that through LLVM C bindings?

If there's not, we should add one. That's something that should be there regardless of this change.

So is it necessary to pass in everything the chip can do? So for Haswell
something like "+avx, +avx2, +bmi, +bmi2, +cmov, +f16c, +fma, +movbe,
+lzcnt, +popcnt, +sse, +sse2, +sse3 +ssse3, sse4.1, sse4.2" and the dozen
others I forgot?

Just specify the CPU. Don't worry about the specific subtarget features.

That said, as mentioned above, unless you're using the MCJIT, you don't want
to specify newer hardware, as the old JIT can't encode some of those
instructions and you'll see crashes as a result.
We can use both mcjit or old jit though generally don't use mcjit on x86 (we used mcjit at a time where the old jit couldn't handle avx).
So I guess we need to "clamp" the cpu (though I wonder what old jit can't handle, all the new features of haswell? We actually have code which assumed llvm would emit avx2 instructions otherwise we did workarounds for emulating true vector shifts I guess that didn't actually work...)

I guess I'll need to figure out how to get that from somewhere - right now
we only detect some stuff for which we emit intrinsics ourselves (notably
most sse versions, avx). Probably the same for the cpu model though I doubt
it makes much of a difference for the generated code as nearly all of it is
simd).

llvm::sys::getHostCPUName() and llvm::sys::getHostCPUFeatures()

Some of the new instructions probably work fine. Anything that the generic tblgen'erated binary encoding function will handle fully will fall out OK. It's stuff that needs anything more than will fall over. In particular, I've seen failures with some of the BMI instructions.