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 explicit handling about it, even if the compiler just optimizes it away.
On Fri, May 17, 2019 at 8:55 PM Jason Ekstrand <ja...@jlekstrand.net> wrote: > > 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_const_opcode to do a u2u32 on the value. > > --Jason > > On Fri, May 17, 2019 at 1:24 AM Karol Herbst <kher...@redhat.com> wrote: >> >> 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 <ja...@jlekstrand.net> 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 <airl...@gmail.com> 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 locations and different types. >> > > >> > > and the following lines, I think it's actually undefined behaviour wrt >> > > the C spec. >> > > >> > > Dave. >> > >> > >> > >> > _______________________________________________ >> > mesa-dev mailing list >> > mesa-dev@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
