[Mesa-dev] [Bug 52209] lp_test_format regression

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=52209

--- Comment #8 from Roland Scheidegger <sroland at 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.