https://bugs.freedesktop.org/show_bug.cgi?id=52209
--- Comment #8 from Roland Scheidegger <srol...@vmware.com> 2012-07-18 02:03:19 PDT --- Ah I think I got it. %24 = shl <4 x i8> %23, <i8 8, i8 8, i8 8, i8 8> This is another extremely questionable shift (count must be smaller than number of bits), coming from lp_build_conv(), line 690). This shift is what probably causes most of the crazy code generated (because there is no native vector byte shift). Most likely this causes the wrong results - since llvm does some really crazy things to emulate this shift, I suspect this emulation can cause wrong results as those crazy things it does probably are only guaranteed to work when the shift count is legal (the code generated is too unreadable to be sure). Note that this format conversion is rather crazy anyway - all values get mapped to either 0 or 1, that shift above is what is done to get those 0/1 values into unorm format (together with the sub following it). In any case I don't think this is really a regression. Most likely we just got lucky before. I think the old code would have used extract/scalar truncation/insert before that shift, hence llvm probably would have just used scalar shifts instead of the complicated emulation (which actually in this case most likely was better). But technically the shift still was undefined. To fix this properly I think we must move arounds those shifts a bit (before/after lp_build_resize()) but that's going to depend on what the src/dst format is. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
