in VEX r2727 (conversion ops between binary floating point and
decimal floating point).
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13428
memcheck/tests/vbit-test fails with unknown opcode after introduction
of new Iops for AVX2, BMI, FMA support #317506
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13347
Update vbit tester. Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ #307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13285
The implementation of integer operands doesn't really match the documentation
for the Iop. Take for example Iop_ExtractExpD64. It is documented as
D64 -> I64 but the implementation of the UNARY is defined as
UNARY(Ity_D64, Ity_D64). The result is an integer that is stored in an integer
format in a floating point register. On the IBM s390 however, the architecture
stores the integer value in a general purpose register (GPR) not a floating
point register. This issue exists with the implementation of 11 Iops where the
PPC implementation has either a source or destination whose value is an integer
but the value is stored in a floating point register in an integer format. After
reviewing the PPC implementation with the s390 developer, it was agreed the
cleanest way to fix this is to change the PPC implementation. The BINOP will be
changed to be consistent with the Iop description. This means the PPC
instruction implementation of the PPC instruction in guest_ppc_toIR.c will need
to reinterpret integer source operands as integers which will move the value
from a floating point register to an integer register before calling binop().
The underlying PPC implementation of the unop() for the specific Iop will also
need to change to move the value from the integer register back to the floating
point register so the native instruction can be issued with the integer value
in a floating point register. It was decided that making the changed in PPC,
rather then having the s390 reinterpret integers as DFP and then move the value
back to an integer register, was preferable as it makes the implementation of
the unop(), binops(), triop() consistent with the definition of the Iop.
This patch also includes the needed changes for the vbit tester. The Iop
definitions in memcheck/tests/vbit-test/util.c had to be updated to be consitent
with the changes in the Iops as documented below. Also, the function mkLazy3()
in memcheck/mc_translate.c had to be updated to handle the I32 x I8 x I64 -> I64
and I32 x I8 x I128 -> I128 cases.
The specific list of changes are as follows:
Iop name in pub/libvex_ir.h
documented type
type of UNARY/BINARY/TERNARY in priv/ir_defs.c
-------------------------------------------------------
Iop_ExtractExpD64
D64 -> I64
UNARY(Ity_D64, Ity_D64); (current)
UNARY(Ity_D64, Ity_I64); (fix)
Iop_ExtractExpD128
D128 -> I64
UNARY(Ity_D128, Ity_D64); (current)
UNARY(Ity_D128, Ity_I64); (fix)
Iop_InsertExpD64
I64 x I64 -> D64
I64 x D64 -> D64 (fix definition)
BINARY(Ity_D64,Ity_D64, Ity_D64); (current)
BINARY(Ity_I64,Ity_D64, Ity_D64); (fix)
Iop_InsertExpD128
I64 x I128 -> D128
I64 x D128 -> D128 (fix definition)
BINARY(Ity_D64,Ity_D128, Ity_D128); (current)
BINARY(Ity_I64,Ity_D128, Ity_D128); (fix)
Iop_I64StoD128
I64S -> D128
UNARY(Ity_D64, Ity_D128); (current)
UNARY(Ity_I64, Ity_D128); (fix)
Iop_D64toI64S
IRRoundingModeDFP(I32) x D64 -> I64
BINARY(ity_RMode, Ity_D64, Ity_D64) (current)
BINARY(ity_RMode, Ity_D64, Ity_I64) (fix)
Iop_D128toI64S
IRRoundingModeDFP(I32) x D128 -> I64
BINARY(ity_RMode, Ity_D128, Ity_D64); (current)
BINARY(ity_RMode, Ity_D128, Ity_I64); (fix)
Iop_I64StoD64
IRRoundingModeDFP(I32) x I64 -> D64
BINARY(ity_RMode, Ity_D64, Ity_D64); (current)
BINARY(ity_RMode, Ity_I64, Ity_D64); (fix)
Iop_SignificanceRoundD64
IRRoundingModeDFP(I32) x I8 x D64 -> D64
TERNARY(ity_RMode,Ity_D64,Ity_D64, Ity_D64); (current)
TERNARY(ity_RMode,Ity_I8,Ity_D64, Ity_D64); (fix)
Iop_SignificanceRoundD128
IRRoundingModeDFP(I32) x I8 x D128 -> D128
TERNARY(ity_RMode,Ity_D128,Ity_D128, Ity_D128); (current)
TERNARY(ity_RMode,Ity_I8,Ity_D128, Ity_D128); (fix)
The patch is for bugzilla 311100
VEX Committed revision 2652
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13260
Adapt vbit-tester.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13224
VEX buddy patch is r2617.
Enhance testcase for CEDTR and CEXTR. Adapt vbit tester.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
This is part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13203
tester. This is part of fixing BZ #307113.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13195
This patch adds code to count the number of each type of test. The
number of 1, 2, 3 and 4 operand tests that are generated by the vbit-tester
are counted and printed by the vbit-tester. The user should refer to the
Valgrind output to see if any of the tests failed.
The existing two verbose levels was increased by one level and the the
new output giving the number of tests was inserted as the first verbose
level. The verbose levels are now:
-v shows the number of 1, 2, 3 and 4 operand tests that are generated
-v -v shows IROps being tested
-v -v -v extreme edition, shows input values
This patch is for bugzilla 309229
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13124
The Iop_CmpORD class of iops support the POWER specific comparison
instructions. The instructions take two 32-bit or 64-bit operands
and produce a result of the same size. However, only the lower bits
of the result are set by the instruction. The bits are set by the instruction
to indicate if the comparison is "less then", "greater then", or "equal".
This patch adds support to the V-bit tester to verify the propagation
of the undefined bits in the inputs to the output for the Iop_CmpORd iops.
The output bits are always set to undefined if any of the input bits are not
defined.
This patch is for bugzilla 310169
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13123
BSF instructions, as the lack of it causes false positives (Valgrind
side). Fixes#308627. (Patrick J. LoPresti <lopresti@gmail.com>)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13108
an immediate constant as the shift amount. This is needed for
powerpc Iop_ShlD64 etc. What it basically means that we do not
iterate over the bits in the 2nd operand because there are no
V-bits to set. An immediate constant is always completely defined.
Fixes bugzilla #305948.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12969
Testcase, vbit tester update, memcheck support for the new IROps,
NEWS announcement and opcode list update.
Patch by Christian Borntraeger (borntraeger@de.ibm.com).
Vbit tester tweaks by myself.
Fixes bugzilla #274695.
See also companion patch VEX r2496.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12921
they cause assertion failures.
Do not test Iop_CmpORDxyz on ppc because the vbit tester does not
support them. This is just so we don't have to add another .exp file for ppc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12910
The tester is located in memcheck/tests/vbit-test.
It needs the following support on the valgrind / VEX side:
(1) a new client request VG_USERREQ__VEX_INIT_FOR_IRI
(2) a new "special instruction" on all architectures inserted via
VALGRIND_VEX_INJECT_IR
(3) VEX changes to detect the special insn and insert IR (ir_inject.c)
The README file in vbit-test has some more information.
See also VEX r2490. Fixes bugzilla #300102.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12906
