From d3fd1c761aab01e06665180ab86c9528c0b285b2 Mon Sep 17 00:00:00 2001 From: Ian Romanick Date: Mon, 26 Aug 2019 13:28:09 -0700 Subject: [PATCH] nir/algrbraic: Don't optimize open-coded bitfield reverse when lowering is enabled This caused a problem on Sandybridge where an open-coded bitfieldReverse() function could be optimized to a nir_op_bitfield_reverse that would generate an unsupported BFREV instruction in the backend. This was encountered in some Unreal4 tech demos in shader-db. The bug was not previously noticed because we don't actually try to run those demos on Sandybridge. The fixes tag is a bit a lie. The actual bug was introduced about 26,000 commits earlier in 371c4b3c48f ("nir: Recognize open-coded bitfield_reverse."). Without the NIR lowering pass, the flag needed to avoid the optimization does not exist. Hopefully nobody will care to fix this on an earlier Mesa release. Reviewed-by: Matt Turner Fixes: 7afa26d4e39 ("nir: Add lowering for nir_op_bitfield_reverse.") --- src/compiler/nir/nir_opt_algebraic.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler/nir/nir_opt_algebraic.py b/src/compiler/nir/nir_opt_algebraic.py index beb7f7978f9..6f0a4393524 100644 --- a/src/compiler/nir/nir_opt_algebraic.py +++ b/src/compiler/nir/nir_opt_algebraic.py @@ -1319,7 +1319,7 @@ def bitfield_reverse(u): return step5 -optimizations += [(bitfield_reverse('x@32'), ('bitfield_reverse', 'x'))] +optimizations += [(bitfield_reverse('x@32'), ('bitfield_reverse', 'x'), '!options->lower_bitfield_reverse')] # For any float comparison operation, "cmp", if you have "a == a && a cmp b" # then the "a == a" is redundant because it's equivalent to "a is not NaN" -- 2.30.2