well, the code was required for the old style load_const as we unioned
the arrays. But now that the load_const data is just one 64 bit value
and we 0 out untouched bits I am quite sure we don't have to adjust
the bit size of the shift anymore? Although I would feel better if we
would have some expl
I'm not convinced that code is correct. In particular, the bit_size value
is for the destination and not necessarily that one source. As Karol
points out, it probably is safe to just delete. However, I'd feel slightly
better about it if we figured out the right bit size and just called
nir_eval_
ohhh, yeah.. I think we can actually just remove that code, as it
shouldn't have any affect on the constants value.
On Fri, May 17, 2019 at 4:07 AM Jason Ekstrand wrote:
>
> I think it's fine but I'm not at my computer right now.
>
> --Jason
>
> On May 16, 2019 20:58:03 Dave Airlie wrote:
>
> >
I think it's fine but I'm not at my computer right now.
--Jason
On May 16, 2019 20:58:03 Dave Airlie wrote:
Coverity gave me this:
mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987:
overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32",
which have overlapping memory locati
Coverity gave me this:
mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987:
overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32",
which have overlapping memory locations and different types.
and the following lines, I think it's actually undefined behaviour wrt
the C spec.
Dave
