gallivm: Never emit llvm.fmuladd on LLVM 3.3.
Besides the old JIT bug, it seems the X86 backend on LLVM 3.3 doesn't handle llvm.fmuladd and instead it fall backs to a C function. Which in turn causes a segfault on Windows. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This commit is contained in:
parent
320d1191c6
commit
2b4cee0571
|
@ -270,6 +270,12 @@ lp_build_fmuladd(LLVMBuilderRef builder,
|
||||||
LLVMTypeRef type = LLVMTypeOf(a);
|
LLVMTypeRef type = LLVMTypeOf(a);
|
||||||
assert(type == LLVMTypeOf(b));
|
assert(type == LLVMTypeOf(b));
|
||||||
assert(type == LLVMTypeOf(c));
|
assert(type == LLVMTypeOf(c));
|
||||||
|
if (HAVE_LLVM < 0x0304) {
|
||||||
|
/* XXX: LLVM 3.3 does not breakdown llvm.fmuladd into mul+add when FMA is
|
||||||
|
* not supported, and instead it falls-back to a C function.
|
||||||
|
*/
|
||||||
|
return LLVMBuildFAdd(builder, LLVMBuildFMul(builder, a, b, ""), c, "");
|
||||||
|
}
|
||||||
char intrinsic[32];
|
char intrinsic[32];
|
||||||
lp_format_intrinsic(intrinsic, sizeof intrinsic, "llvm.fmuladd", type);
|
lp_format_intrinsic(intrinsic, sizeof intrinsic, "llvm.fmuladd", type);
|
||||||
LLVMValueRef args[] = { a, b, c };
|
LLVMValueRef args[] = { a, b, c };
|
||||||
|
|
|
@ -570,7 +570,7 @@ lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
|
||||||
*/
|
*/
|
||||||
MAttrs.push_back(util_cpu_caps.has_avx ? "+avx" : "-avx");
|
MAttrs.push_back(util_cpu_caps.has_avx ? "+avx" : "-avx");
|
||||||
MAttrs.push_back(util_cpu_caps.has_f16c ? "+f16c" : "-f16c");
|
MAttrs.push_back(util_cpu_caps.has_f16c ? "+f16c" : "-f16c");
|
||||||
if (HAVE_LLVM >= 0x0304 || useMCJIT) {
|
if (HAVE_LLVM >= 0x0304) {
|
||||||
MAttrs.push_back(util_cpu_caps.has_fma ? "+fma" : "-fma");
|
MAttrs.push_back(util_cpu_caps.has_fma ? "+fma" : "-fma");
|
||||||
} else {
|
} else {
|
||||||
/*
|
/*
|
||||||
|
|
Loading…
Reference in New Issue