This reverts commit 1f29f4db1e867357a119c0c7c34fb54dc27fb682.
For this to work the compiler must ensure that it never puts
the values that arrive to this helper into unsigned variables
at any point in its processing, since that would not apply sign
extension to the value and it would break the expectations here.
Unfortunately, we use uint64_t extensively to pass and copy
things around, so some times we get to this helper with values
that are not properly sign extended to 64-bit. Here is an example
for an 8-bit value that comes from a switch case:
(gdb) p /x x
$1 = 0xffffffd6
The value seems to have been copied to a 32-bit value at some point
getting proper sign extension, but then copied into a uint64_t
which wont' apply sign extension, breaking the expectations of
the assertion.
---
FWIW, I tracked down the case where we were producing this and fixed
it, then the test that triggered this problem started to pass... but
others started to fail so I think it is best that we remove the assert
for now. If we want to keep this then I think we might need to do a
careful review of the compiler code and make sure we don't use any
unsigned types to copy things around to ensure that sign extension
happens consistently throughout.
src/compiler/nir/nir_builder.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index e37aba23dc..30fa1d7ec8 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -330,10 +330,6 @@ nir_imm_intN_t(nir_builder *build, uint64_t x, unsigned
bit_size)
{
nir_const_value v;
- assert(bit_size == 64 ||
- (int64_t)x >> bit_size == 0 ||
- (int64_t)x >> bit_size == -1);
-
memset(&v, 0, sizeof(v));
assert(bit_size <= 64);
v.i64[0] = x & (~0ull >> (64 - bit_size));
--
2.17.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
