gallivm: remove workaround for reversing optimization pass order.

32bit code generation and llvm >= 2.7 used a different optimization pass
order - this code was initially introduced (2010-07-23) by
815e79e72c1f4aa849c0ee6103621685b678bc9d, apparently due to buggy code being
generated with then brand new llvm versions (which was llvm 2.7 plus pre 2.8
devel).
It seems very highly likely that whatever this bug was it has been fixed in
newer llvm versions, though there's no easy way to test this - the mentioned
piglit test has been removed years ago, and even if you'd build it I'm
sceptical the glsl compiler would still produce the required code to trigger
it.
I have no idea what a good order of passes is, but just remove the workaround
and use the same order everywhere.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index a39c1a3..4ad5797 100644 (file)
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -147,19 +147,8 @@ create_pass_manager(struct gallivm_state *gallivm)
       LLVMAddLICMPass(gallivm->passmgr);
       LLVMAddCFGSimplificationPass(gallivm->passmgr);
       LLVMAddReassociatePass(gallivm->passmgr);
-
-      if (sizeof(void*) == 4) {
-         /* XXX: For LLVM >= 2.7 and 32-bit build, use this order of passes to
-          * avoid generating bad code.
-          * Test with piglit glsl-vs-sqrt-zero test.
-          */
-         LLVMAddConstantPropagationPass(gallivm->passmgr);
-         LLVMAddPromoteMemoryToRegisterPass(gallivm->passmgr);
-      }
-      else {
-         LLVMAddPromoteMemoryToRegisterPass(gallivm->passmgr);
-         LLVMAddConstantPropagationPass(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