https://bugs.kde.org/show_bug.cgi?id=476025
Eyal <eyals...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eyals...@gmail.com
--- Comment #5 from Eyal <eyals...@gmail.com> ---
I'll write some details to explain what is going on here.
In this commit: 26a3abd27db2ef63dafea1ecab00e8239f341f0f
The handling of pcmpgt was improved. The pcmpgt operation takes two 128-bit
registers and treats every (8/16/32/64) bits as a separate word and then is
tests them for "greater than".
Before the commit 26a3abd2, valgrind just looked for any undefined bits in one
or the other register and said that if some all undefined then the whole result
is undefined. valgrind was doing the wrong thing. This caused false positives
for me in a newish version of clang so I put in the expensive check which now
calculates the "greater than" despite undefinedness and does the best possible
computation.
Unrelated to that fix, the vbits test checks that vbits work correctly. It
tests operations and checks that the vbits generated are correct. For many
operations, it's too hard to generate the correct vbits off an input so the
operation is marked as "UNDEF_UNKNOWN", indicating that the vbits for that
operation are too hard to calculate so we just won't test this one.
All the Iop_CmpGT... operations ( there are 2-0 of them) in the vbits test are
marked as "UNDEF_UNKNOWN" except for Iop_CmpGT64Ux2. This was probably a
mistake when it was written. For that one, it checks that the vbits that are
output are doing the wrong thing in the way that valgrind also does the wrong
thing. Basically, it was confirming that valgrind is doing the wrong thing in
the way that we expect valgrind to be wrong.
Well, now valgrind works and so the test is getting hung up because it's
checking that valgrind is still "broken". But it isn't. I never noticed this
in my testing because it only tested on ppc platforms.
The solution is to first set that test to UNDEF_UNKNOWN. That'll get the tests
working again.
The follow-up, if we want, is to convert all those UNDEF_UNKNOWNS into
UNDEF_somethingelse that actually checks correctness. Now, is that the right
thing to do? Maybe. On the one hand, it makes the testing more complete. On
the other hand, the guy that wrote the expensiveCmpGT (me) is going to write
the UNDEF_CMP_GT (me again) it's like me grading my own homework and declaring
100% on myself. Not a very robust test! However, the vbits code is in regular
c++ and not the VEX IR thing so there is some value to it that way. And I can
see in the vbits test that ADD, SUB, etc, *are* handled (not UNDEF_UNKNOWN) and
cmpgt is similar to those. So maybe we should do it.
I think that it wouldn't be too difficult to do given that we can pretty much
copy the ADD and SUB examples. We'll need permuations for the various bit
widths, signed/unsigned, and number of lanes. But not too bad. I'd probably
still skip the floating point ones because that seems harder to me. Maybe it's
not, though? I dunno.
--
You are receiving this mail because:
You are watching all bug changes.
