instruction: dcbzl" submitted by Anmol P. Paralkar <paralkar@freescale.com>
The patch adds the following files:
none/tests/ppc64/data-cache-instructions.vgtest
none/tests/ppc64/data-cache-instructions.c
none/tests/ppc64/data-cache-instructions.stdout.exp
none/tests/ppc64/data-cache-instructions.stderr.exp
none/tests/ppc32/data-cache-instructions.stdout.exp
none/tests/ppc32/data-cache-instructions.c
none/tests/ppc32/data-cache-instructions.vgtest
none/tests/ppc32/data-cache-instructions.stderr.exp
tests/power_insn_available.c
The following files are modified:
none/tests/ppc32/Makefile.am
none/tests/ppc64/Makefile.am
tests/Makefile.am
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13791
Tests for lhux, lwux, and lbx for Cavium Octeon II.
Patch by Zahid Anwar, with changes.
Related to Bugzilla issue 326444.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13786
instructions.
The patch also adds ppc32 and ppc64 test cases for the instructions.
The patch is a fix for bugzilla 329956 "valgrind crashes when lmw/stmw instructions are used on ppc64".
The VEX code commit is 2802
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13780
Fix some typo error and some errors in tests that was discovered while running Valgrind on MIPS/Android.
In some cases initial FCSR value wasn't being set properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13746
make dist will not copy header files if they are not explicitly listed
in EXTRA_DIST. This change adds missing header files from none/test/mips64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13701
vaddcuq, vadduqm, vaddecuq, vaddeuqm,
vsubcuq, vsubuqm, vsubecuq, vsubeuqm,
vbpermq and vgbbd.
The completes adding the Power ISA 2.07 support.
Bugzilla 325816
VEX commit id 2790
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13653
A previous commit had decreased to 6 (on android) and increased to 16
(other platforms) the nr of sectors in the translation cache.
This patch adds a command line option to let the user specify
the nr of sectors as e.g. 16 sectors might be a lot and cause
an out of memory for some workloads or might be too small for
huge executable or executables using a lot of shared libs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13652
This commit adds the testcases for the following instructions:
vpmsumb, vpmsumh, vpmsumw, vpmsumd, vpermxor, vcipher, vcipherlast,
vncipher, vncipherlast, vsbox,
vclzb, vclzw, vclzh, vclzd,
vpopcntb, vpopcnth, vpopcntw, vpopcntd,
vnand, vorc, veqv,
vshasigmaw, vshasigmad,
bcdadd, bcdsub
The VEX commit that added the support for the above instructions was
commit 2789.
The patch is for Bugzilla 325628
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13646
Change the input values so that the binary values
is representing exactly the same float values.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13632
The initial Transactional Memory instruction patch did not include the two
privileged (OS) instructions treclaim and trechkpt. VEX commit 2784 added
the support for these two instructions.
This patch adds a touch test to make sure all of the POWER Transactional
memory instrutions are recognized by Valgrind. All of the the Transactional
Memory instructions, with the exception of tbegin, are treated as NOPs in the
first implementation. The tbegin instruction causes the transaction to fail
thus no additional Transactional Memory instructions on the successful
transaction path would be executed in a real program. This test just makes
sure each instruction is actually recognized by Valgrind.
The patch if for Bugzilla 325751.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13630
Those tests were rejected by clang and according to the
analysis below by Tom Hughes do not add anything new.
Analysis:
I'm not 100% sure that clang is right though - the Intel manual
clearly describes that argument as "reg" rather than "r32" which
is why I will have included the 64 bit version in the test. It also says:
"The upper bits of r32 or r64 is zeroed."
and:
"If the destination operand is a general-purpose register, the
default operand size is 64-bits in 64-bit mode."
which basically means that REX.W is implied for this op and there is
no way to encode a 32 bit version when running in 64 bit mode.
So in principle you could encode it as:
44 0f c5 ce 00 pextrw $0x0,%mm6,%r9d
or:
4c 0f c5 ce 00 pextrw $0x0,%mm6,%r9
but in fact gcc assembles both versions to the first form.
Equally you could argue that as REX.W is implied both versions
should disassemble as %r9.
So I think clang is being overly picky, and if it was only going to
accept one version I would argue it should be %r9 not %r9d!
In practical terms dropping the second set of tests doesn't lose us anything though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13614
This patch adds testcases for the following instructions added
in phase 4. The instructions are for doing various arithmetic,
logic, and load/store VSX operations:
xscvsxdsp xscvuxdsp xsaddsp xssubsp xsdivsp xsmaddasp xsmaddmsp
xsmsubasp xsmsubmsp xsnmaddasp xsnmaddmsp xsnmsubasp xsnmsubmsp
xsmulsp xssqrtsp xsresp xsrsqrtesp xsrsp xxlorc xxlnand xxleqv
lxsiwzx lxsiwax lxsspx stxsiwx stxsspx
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
VEX commit for the instruction support r2781
Bugzilla 325477
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13611
as suggested by John Reiser and Greg Parker.
It seems that GCC has a more relaxed attitude about what it accepts
as valid input.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13610
compilers as the -mhtm flag is not known. The patch fixes the makefile
issue and addes #defines to the testcase code.
The testcase was added in valgrind commit 13607.
The bugzilla for adding the TM instruction support is 323803
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13608
The test case for the transaction memory instructions executes the
failure path when run under valgrind. This is since the initial
Transaction Memory implemnetation is to simply fail the TBEGIN instruction
forcing the execution flow to take the failure path. When the
test case is executed on the real hardware, the success path will
be taken. Only the TBEGIN instruction actually does anything. All other
transactional memory instructions are NOPs since only failure path is executed
and it assumed to not have any transactional memory instructions on it.
Signed-off-by: Carl Love <cel@us.ibm.com>
VEX commit revision 2780
Bugzilla 323803
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13607
This patch adds testcases to an existing testcase
source file to test the new instructions which were
added to VEX support in the phase 3 ISA 2.07 code patch.
The patch also makes a small change to memcheck's
vbit tester code to allow successful execution.
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Bugzilla 324894. Corresponding VEX commit 2779
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13594
The assembly of these instructions is not alwasy being done correctly as
described in the following email reply.
Re: Assembling Power instructions: dcbtst/dcbt.
From: Peter Bergner <bergner at vnet dot ibm dot com>
To: Paralkar Anmol-B07584 <B07584 at freescale dot com>
Cc: "amodra at bigpond dot net dot au" <amodra at bigpond dot net dot au>, "binutils at sourceware dot org" <binutils at sourceware dot org>
Date: Fri, 13 Sep 2013 15:22:35 -0500
Subject: Re: Assembling Power instructions: dcbtst/dcbt.
Authentication-results: sourceware.org; auth=none
References: <DC6D7B34688246489A6578981A5ADEB9302A07 at 039-SN2MPN1-012 dot 039d dot mgd dot msft dot net>
On Fri, 2013-09-13 at 18:32 +0000, Paralkar Anmol-B07584 wrote:
> Hello,
>
> Per Power ISA Version 2.07 (May 3, 2013) "4.3.2 Data Cache Instructions",
> the assembly language syntax for the dcbtst instruction (pp. 771) is:
>
> dcbtst RA,RB,TH [Category: Server]
> dcbtst TH,RA,RB [Category: Embedded]
>
> and it's layout in the object code is:
>
> +------+------+------+------+------------+---+
> | 31 | TH | RA | RB | 246(0xF6) | / |
> |0 |6 |11 |16 |21 |31 |
> +------+------+------+------+------------+---+
>
> (Analogously: dcbt pp. 770)
>
> However, GAS (as of version 2.23.52.20130912) decides on the syntax to use based on
> processor/architecture dialect (not Power ISA Category), using the Server syntax in
> the case of POWER4 and the Embedded syntax for generic PPC or VLE.
That was a bug fixed here:
https://sourceware.org/ml/binutils/2012-11/msg00352.html
> Consequently (e.g.),
>
> dcbtst 17, 14, 6
>
> in the assembly file gets "misassembled" under -many for a user-space program on Linux:
When you only specify -many (and not one of -mpower4, -mpower5, etc.),
the assembler/disassembler will choose a default -m<CPU> value for
you. That has changed over time, but is generally one of the newer
server cpus. For example, for binutils trunk, the default is now
-mpower8 and for your 2.23.x binutils, it is -mpower7.
That should force the assembler and disassembler to assemble
the instruction using the server operand order you want, but the bug
above (which is in 2.23) basically resets it to an old cpu, so it
chooses to use the embedded/old cpu setting.
The patch from Amodra fixes the issue by manually generating the correct
hex value for the instruction rather then leaving it to the assembler to
generate the hex value from the symbolic assembly instruction name.
This is the fix for Bugzilla 324765.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13562
Change the existing tests to print the value of the FCSR
register after the mips fpu instruction is executed.
Add tests that are testing the value of FCSR register.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13560
As this file is now detecting mips64/Cavium boards, we are renaming it to
reflect that. The functional change is that mips_features now can detect
Cavium board and allow Cavium-specific tests to be run.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13551
behavior of the xscvspdp instruction, indicating that if the source argument
is a SNaN, it is first changed to a QNaN before being converted from
single-precision to double-precision. This updated information about the
xscvspdp instruction exposed a bug in the VEX implementation for that
instruction and also a bug in the testing for all instructions having
special behavior for single-precision SNaN arguments.
The VEX code fix for this issue is r2760.
This patch fixes the test cases for the ISA 2.07.
Testing bug: In several ppc[64] test cases, an array of special
double-precision floating point values is set up, and then all elements of
that array are copied via assignment to a single-precision array ('float'
type). Assignment from a double to a float works fine for all cases, except for
SNaN values. In the case of a SNaN, the source is changed to a QNaN and then
converted to single-precision. So the end result was that our array of floats
did not have an actual SNaN value, and, therefore, any instructions that had
special behavior for a single-precision SNaN input argument was never being
properly tested. This patch makes some functional changes in the following
testcases:
none/tests/ppc[32|64]/test_isa_2_06_part2.c
none/tests/ppc[32|64]/test_isa_2_06_part3.c
none/tests/ppc[32|64]/test_isa_2_07_part2.c
These changes impacted the associated *.stdout.exp files, so the patch also
updates those files. Additionally, there were several errors in testcase
source comments that misidentified QNaN and SNaN bit patterns which this patch
corrects.
See bugzilla 324816.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13544
