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 in371c4b3c48
("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 <mattst88@gmail.com> Fixes:7afa26d4e3
("nir: Add lowering for nir_op_bitfield_reverse.")
This commit is contained in:
parent
4662b70d23
commit
d3fd1c761a
|
@ -1319,7 +1319,7 @@ def bitfield_reverse(u):
|
||||||
|
|
||||||
return step5
|
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"
|
# 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"
|
# then the "a == a" is redundant because it's equivalent to "a is not NaN"
|
||||||
|
|
Loading…
Reference in New Issue