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

Reply via email to