Commits
mips64n32
Name already in use
Commits on Apr 22, 2015
-
-
-
-
-
-
-
mips: Add support for the cavium LHX instruction
This is like LHUX but with sign extensions instead.
-
mips64: Explicitly narrow the source for CmpNEZ32
This fixes bug 341481
Commits on Apr 21, 2015
-
Add spec rules for EQ, MI, PL, GT and LE after COPY. These result
from floating point comparisons. git-svn-id: svn://svn.valgrind.org/vex/trunk@3139 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedApr 21, 2015
Commits on Apr 20, 2015
-
Fix for an error in the stq, stqcx, lqarx and lq instructions with LE.
git-svn-id: svn://svn.valgrind.org/vex/trunk@3138 8f6e269a-dfd6-0310-a8e1-e2731360e62c
carll committedApr 20, 2015
Commits on Apr 17, 2015
-
Add support for the lbarx, lharx, stbcx and sthcs instructions.
The instructions are part of the ISA 2.06 but were not implemented in all versions of hardware. The four instructions are all supported in ISA 2.07. The instructions were put under the ISA 2.07 category of supported instructions in this patch. The bugzilla for this issue is 346324. git-svn-id: svn://svn.valgrind.org/vex/trunk@3137 8f6e269a-dfd6-0310-a8e1-e2731360e62c
carll committedApr 17, 2015
Commits on Apr 16, 2015
-
The vbpermq for Powerpc64 big endian has the same issue as the little
endian support. Bugzilla 346270 was reopened to include the BE issue. The bugzilla for the issue is 346270. git-svn-id: svn://svn.valgrind.org/vex/trunk@3136 8f6e269a-dfd6-0310-a8e1-e2731360e62c
carll committedApr 16, 2015 -
The following regression tests failures occur on PPC64 little endian …
…only. The regression test none/tests/jm_vec/isa_2_07 has failures on the lxsiwax and lxsiwzx instructions. They are loads and the the results are correct for big endian but not little endian. The little endian result matches the expected big endian result. The regresssion test none/tests/test_isa_2_07_part2 has a failure with the vbpermq instruction. The little endian result matches the expected result for big endian. The upper and lower 64 bits of the result are not swapped correctly for little endian. This commit fixes these issues. The bugzilla for the issue is 346270. git-svn-id: svn://svn.valgrind.org/vex/trunk@3134 8f6e269a-dfd6-0310-a8e1-e2731360e62c
carll committedApr 16, 2015
Commits on Apr 15, 2015
-
Add Iop_Add8, Iop_Add16 and other 8 or 16 bit ALU Iop
in the host_tilegx_isel.c They were removed during the code review. But without them, the memcheck's vbit-test failed. So, simply add them back. -This line, and those below, will be ignored-- M host_tilegx_isel.c git-svn-id: svn://svn.valgrind.org/vex/trunk@3133 8f6e269a-dfd6-0310-a8e1-e2731360e62c
zliu committedApr 15, 2015 -
Delete extern in front of function TILEGXInstr *TILEGXInstr_Acas(.) in host_tilegx_defs.c. By: Zhi-Gang Liu git-svn-id: svn://svn.valgrind.org/vex/trunk@3132 8f6e269a-dfd6-0310-a8e1-e2731360e62c
zliu committedApr 15, 2015 -
Removed #if __tilegx__ ... #endif in guest_tilegx_toIR.c
Also eliminated several gcc warning message for this file. By: Zhi-Gang Liu zhg.liu@gmail.com git-svn-id: svn://svn.valgrind.org/vex/trunk@3131 8f6e269a-dfd6-0310-a8e1-e2731360e62c
zliu committedApr 15, 2015 -
Fix the evCheck assertion for TileGX
Quote from Philippe's original email. "When guest = amd64 and host = TILEGX, the libvexmultiarch_test asserts in TILEGX code: vex: priv/host_tilegx_defs.c:2361 (emit_TILEGXInstr): Assertion `evCheckSzB_TILEGX() == (UChar*)p - (UChar*)p0' failed." This patch make sure that evCheck always emits exact 80 bytes instruction stream. By: Zhi-Gang Liu zhg.liu@gmail.com git-svn-id: svn://svn.valgrind.org/vex/trunk@3130 8f6e269a-dfd6-0310-a8e1-e2731360e62c
zliu committedApr 15, 2015
Commits on Apr 13, 2015
-
Remove unused function "lshift".
git-svn-id: svn://svn.valgrind.org/vex/trunk@3128 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedApr 13, 2015
Commits on Apr 11, 2015
-
VEX side for revision 15084 (multi arch testing)
git-svn-id: svn://svn.valgrind.org/vex/trunk@3125 8f6e269a-dfd6-0310-a8e1-e2731360e62c
philippe committedApr 11, 2015
Commits on Apr 10, 2015
-
Add a port to Linux/TileGx. Zhi-Gang Liu (zliu@tilera.com)
VEX aspects. See bug 339778 - Linux/TileGx platform support to Valgrind git-svn-id: svn://svn.valgrind.org/vex/trunk@3124 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedApr 10, 2015
Commits on Apr 9, 2015
-
Fix a typo in the example given in the comment
git-svn-id: svn://svn.valgrind.org/vex/trunk@3123 8f6e269a-dfd6-0310-a8e1-e2731360e62c
philippe committedApr 9, 2015
Commits on Apr 7, 2015
-
x86 front and back ends: track vex r3120, which changed the type of
Iop_Sqrt64Fx2 and Iop_Sqrt32Fx4. git-svn-id: svn://svn.valgrind.org/vex/trunk@3122 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedApr 7, 2015 -
amd64 front and back ends: track the change of type of Iop_Sqrt32Fx4
and Iop_Sqrt64Fx2 as introduced in r3120, in which they acquired a rounding-mode argument. git-svn-id: svn://svn.valgrind.org/vex/trunk@3121 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedApr 7, 2015
Commits on Apr 6, 2015
-
arm64: implement FSQRT 2d_2d, 4s_4s, 2s_2s
AFAICS this completes the AArch64 SIMD implementation, except for the crypto instructions. This changes the type of Iop_Sqrt64x2 and Iop_Sqrt32x4 so as to take a rounding mode argument. This will (temporarily, of course) break all of the other targets that implement vector fsqrt. git-svn-id: svn://svn.valgrind.org/vex/trunk@3120 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedApr 6, 2015 -
arm64: add support for the following insns. This completes support
for conversion instructions. SCVTF d_d_imm, s_s_imm UCVTF d_d_imm, s_s_imm FCVTZS d_d_imm, s_s_imm FCVTZU d_d_imm, s_s_imm FCVTXN s_d SCVTF d_d, s_s UCVTF d_d, s_s SCVTF {2d_2d,4s_4s,2s_2s}_imm UCVTF {2d_2d,4s_4s,2s_2s}_imm FCVTZS {2d_2d,4s_4s,2s_2s}_imm FCVTZU {2d_2d,4s_4s,2s_2s}_imm FCVTXN 2s/4s_2d FCVTZ{S,U} {w,x}_{s,x}_#fbits git-svn-id: svn://svn.valgrind.org/vex/trunk@3119 8f6e269a-dfd6-0310-a8e1-e2731360e62csewardj committedApr 6, 2015
Commits on Apr 4, 2015
-
Tweak STATIC_ASSERT such that there is no warning about an unused
variable when used at block scope. git-svn-id: svn://svn.valgrind.org/vex/trunk@3118 8f6e269a-dfd6-0310-a8e1-e2731360e62c
florian committedApr 4, 2015
Commits on Apr 1, 2015
-
Add the standard end of the file marker used elsewhere
git-svn-id: svn://svn.valgrind.org/vex/trunk@3116 8f6e269a-dfd6-0310-a8e1-e2731360e62c
philippe committedApr 1, 2015 -
Improve comments, add the copyright notice
git-svn-id: svn://svn.valgrind.org/vex/trunk@3115 8f6e269a-dfd6-0310-a8e1-e2731360e62c
philippe committedApr 1, 2015
Commits on Mar 31, 2015
-
This patch reduces the size of all tools by about 2MB of text
(depending on the arch). This has as advantages: 1. somewhat faster build/link time (very probably neglectible) 2. somewhat faster tool startup (probably neglectible for most users, but regression tests are helped by this) 3. a gain in memory of about 10MB The valgrind tools are making the assumption that host and guest are the same. So, no need to drag the full set of archs when linking a tool. The VEX library is nicely split in arch independent and arch dependent objects. Only main_main.c is dragging the various arch specific files. So, main_main.c (the main entry point of the VEX library) is compiled only for the current guest/host arch. The disadvantage of the above is that the VEX lib cannot be used anymore with host and guest different, while VEX is able to do that (i.e. does not make the assumption that host and guest are the same). So, to still allow a VEX user to use the VEX lib in a multi arch setup, main_main.c is compiled twice: 1. in 'single arch mode', going in the libvex-<arch>-<os> 2. in 'multi arch mode', going in a new lib libvexmultiarch-<arch>-<os> A VEX user can choose at link time to link with the main_main that is multi-arch, by linking with both libs (the multi arch being the first one). Here is a small (rubbish crashing) standalone usage of the VEX lib, first linked in single arch, then linked in multi-arch: // file t1.c #include <stdio.h> #include <libvex.h> void main() { (void)LibVEX_Translate(NULL); } $ gcc -I Inst/include/valgrind -c -g t1.c $ gcc -o t1 t1.o -LInst/lib/valgrind -lvex-x86-linux -lgcc $ gcc -o t1multi t1.o -LInst/lib/valgrind -lvexmultiarch-x86-linux -lvex-x86-linux -lgcc $ size t1 t1multi text data bss dec hex filename 519393 556 5012188 5532137 5469e9 t1 2295717 1740 5015144 7312601 6f94d9 t1multi In a next commit, some regtests will be added to validate that the two libs are working properly (and that no arch specific symbol is missing when linking multi-arch) git-svn-id: svn://svn.valgrind.org/vex/trunk@3113 8f6e269a-dfd6-0310-a8e1-e2731360e62cphilippe committedMar 31, 2015
Commits on Mar 30, 2015
-
FCVT{N,M,A,P,Z}{S,U} 2d_2d, 4s_4s, 2s_2s git-svn-id: svn://svn.valgrind.org/vex/trunk@3112 8f6e269a-dfd6-0310-a8e1-e2731360e62csewardj committedMar 30, 2015 -
FCVT{N,M,A,P,Z}{S,U} d_d, s_s FCVTN 4h/8h_4s, 2s/4s_2d FCVTL 4s_4h/8h, 2d_2s/4s FCVT Sd, Hn FCVT Dd, Hn FCVT Hd, Sn FCVT Hd, Dn git-svn-id: svn://svn.valgrind.org/vex/trunk@3111 8f6e269a-dfd6-0310-a8e1-e2731360e62csewardj committedMar 30, 2015 -
Add IR level support for 16 bit floating point types (Ity_F16) and add
four new IROps that use it: Iop_F16toF64, Iop_F64toF16, Iop_F16toF32, Iop_F32toF16. git-svn-id: svn://svn.valgrind.org/vex/trunk@3110 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedMar 30, 2015
Commits on Mar 28, 2015
-
Add STATIC_ASSERT. Remove VG__STRING.
git-svn-id: svn://svn.valgrind.org/vex/trunk@3109 8f6e269a-dfd6-0310-a8e1-e2731360e62c
florian committedMar 28, 2015 -
mips64: extract correct immediate value for Cavium SEQI and SNEI
Extract immediate value from bit fields [15:6] instead of [15:0]. This fixes the issue reported in BZ #341997. Related Valgrind commit - r15043. Patch by Maran Pakkirisamy. git-svn-id: svn://svn.valgrind.org/vex/trunk@3108 8f6e269a-dfd6-0310-a8e1-e2731360e62c
petarj committedMar 28, 2015
Commits on Mar 26, 2015
-
Bug 345215 - Performance improvements for the register allocator
The basic idea is to change the representation of registers (HReg) so as to give Real registers a unique integer index starting from 0, with the registers available for allocation numbered consectively from zero upwards. This allows the register allocator to index into its primary data structure -- a table tracking the status of each available register -- using normal array index instead of having to search sequentially through the table, as now. It also allows an efficient bitmap-based representation for "set of Real registers", which is important for the NCODE work. There are various other perf improvements, most notably in calling getRegUsage once rather than twice per instruction. Cost of register allocation is reduced to around 65% ish of what it previously was. This translates in to speedups close to zero for compute intensive code up to around 7% for JITing intensive situations, eg "time perl tests/vg_regtest memcheck/tests/amd64". git-svn-id: svn://svn.valgrind.org/vex/trunk@3107 8f6e269a-dfd6-0310-a8e1-e2731360e62c
sewardj committedMar 26, 2015