From: Roland Scheidegger <srol...@vmware.com>
This workaround doesn't list any llvm version, but it was introduced
2010-06-10 (e277d5c1f6b2c5a6d202561e67d2b6821a69ecc4). It is unlikely
this bug is still present in llvm versions we support (3.1+).
There's no specific test listed, but I ran lp_test_arit (which uses
the mentioned functions) on llvm 3.1 and 3.3 with sse41 disabled and
this pass enabled without issues.
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 4ad5797..83ffad9 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -149,14 +149,7 @@ create_pass_manager(struct gallivm_state *gallivm)
LLVMAddReassociatePass(gallivm->passmgr);
LLVMAddPromoteMemoryToRegisterPass(gallivm->passmgr);
LLVMAddConstantPropagationPass(gallivm->passmgr);
-
- if (util_cpu_caps.has_sse4_1) {
- /* FIXME: There is a bug in this pass, whereby the combination
- * of fptosi and sitofp (necessary for trunc/floor/ceil/round
- * implementation) somehow becomes invalid code.
- */
- LLVMAddInstructionCombiningPass(gallivm->passmgr);
- }
+ LLVMAddInstructionCombiningPass(gallivm->passmgr);
LLVMAddGVNPass(gallivm->passmgr);
}
else {
--
1.9.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
