You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(1) |
2
|
|
3
(5) |
4
(7) |
5
(16) |
6
(7) |
7
(5) |
8
|
9
|
|
10
(3) |
11
(7) |
12
(7) |
13
(15) |
14
(4) |
15
(8) |
16
(10) |
|
17
(1) |
18
(7) |
19
(5) |
20
(17) |
21
(10) |
22
(5) |
23
|
|
24
|
25
|
26
(10) |
27
(21) |
28
(18) |
29
(7) |
30
(4) |
|
From: Divya V. <div...@in...> - 2011-04-28 22:31:56
|
I am out of the office until 05/10/2011. I will respond to your message when I return. Note: This is an automated response to your message "Valgrind-developers Digest, Vol 59, Issue 61" sent on 29/4/11 0:06:57. This is the only notification you will receive while this person is away. |
|
From: <sv...@va...> - 2011-04-28 21:04:01
|
Author: sewardj
Date: 2011-04-28 22:03:54 +0100 (Thu, 28 Apr 2011)
New Revision: 2136
Log:
Handle Iop_Not64 when doing 32-bit code generation. Also, assert that
iselWordExpr_R is not asked to handle Iop_Not64 in 32-bit mode.
Fixes #270856. (Maynard Johnson, may...@us...)
Modified:
trunk/priv/host_ppc_isel.c
Modified: trunk/priv/host_ppc_isel.c
===================================================================
--- trunk/priv/host_ppc_isel.c 2011-04-28 20:13:45 UTC (rev 2135)
+++ trunk/priv/host_ppc_isel.c 2011-04-28 21:03:54 UTC (rev 2136)
@@ -1615,6 +1615,7 @@
case Iop_Not16:
case Iop_Not32:
case Iop_Not64: {
+ if (op_unop == Iop_Not64) vassert(mode64);
HReg r_dst = newVRegI(env);
HReg r_src = iselWordExpr_R(env, e->Iex.Unop.arg);
addInstr(env, PPCInstr_Unary(Pun_NOT,r_dst,r_src));
@@ -2885,6 +2886,18 @@
return;
}
+ case Iop_Not64: {
+ HReg xLo, xHi;
+ HReg tmpLo = newVRegI(env);
+ HReg tmpHi = newVRegI(env);
+ iselInt64Expr(&xHi, &xLo, env, e->Iex.Unop.arg);
+ addInstr(env, PPCInstr_Unary(Pun_NOT,tmpLo,xLo));
+ addInstr(env, PPCInstr_Unary(Pun_NOT,tmpHi,xHi));
+ *rHi = tmpHi;
+ *rLo = tmpLo;
+ return;
+ }
+
/* ReinterpF64asI64(e) */
/* Given an IEEE754 double, produce an I64 with the same bit
pattern. */
|
|
From: Christian B. <bor...@de...> - 2011-04-28 20:31:39
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-04-28 22:10:01 CEST Ended at 2011-04-28 22:30:52 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 460 tests, 6 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Christian B. <bor...@de...> - 2011-04-28 20:29:02
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2011-04-28 22:10:01 CEST Ended at 2011-04-28 22:28:52 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 461 tests, 6 stderr failures, 0 stdout failures, 0 post failures == none/tests/faultstatus (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: <sv...@va...> - 2011-04-28 20:14:55
|
Author: sewardj Date: 2011-04-28 21:14:48 +0100 (Thu, 28 Apr 2011) New Revision: 11718 Log: s390x : misc cleanups - Forgotten cleanups in none/tests/s390x/Makefile.am Partial fix for #271501. (Florian Krohm, br...@ac...) Modified: trunk/none/tests/s390x/Makefile.am Modified: trunk/none/tests/s390x/Makefile.am =================================================================== --- trunk/none/tests/s390x/Makefile.am 2011-04-28 18:36:49 UTC (rev 11717) +++ trunk/none/tests/s390x/Makefile.am 2011-04-28 20:14:48 UTC (rev 11718) @@ -15,15 +15,6 @@ $(addsuffix .stderr.exp,$(INSN_TESTS)) \ $(addsuffix .stdout.exp,$(INSN_TESTS)) \ $(addsuffix .vgtest,$(INSN_TESTS)) \ - $(addsuffix .stderr.exp,$(INSN_EI)) \ - $(addsuffix .stdout.exp,$(INSN_EI)) \ - $(addsuffix .vgtest,$(INSN_EI)) \ - $(addsuffix .stderr.exp,$(INSN_GE)) \ - $(addsuffix .stdout.exp,$(INSN_GE)) \ - $(addsuffix .vgtest,$(INSN_GE)) \ - $(addsuffix .stderr.exp,$(INSN_Z196)) \ - $(addsuffix .stdout.exp,$(INSN_Z196)) \ - $(addsuffix .vgtest,$(INSN_Z196)) \ ex_sig.stdout.exp ex_sig.stderr.exp ex_sig.vgtest \ ex_clone.stdout.exp ex_clone.stderr.exp ex_clone.vgtest \ test.h opcodes.h add.h and.h div.h insert.h \ |
|
From: <sv...@va...> - 2011-04-28 20:13:53
|
Author: sewardj
Date: 2011-04-28 21:13:45 +0100 (Thu, 28 Apr 2011)
New Revision: 2135
Log:
s390x : misc cleanups
- Remove fixs390 regarding storing the instruction address in the
IP_AT_SYSCALL slot in the guest state. I'm not sure this is used
but it certainly makes sense.
- Remove fixs390 in function s390_irgen_XONC. This was missed in
VEX r2113.
Partial fix for #271501. (Florian Krohm, br...@ac...)
Modified:
trunk/priv/guest_s390_toIR.c
Modified: trunk/priv/guest_s390_toIR.c
===================================================================
--- trunk/priv/guest_s390_toIR.c 2011-04-28 18:48:06 UTC (rev 2134)
+++ trunk/priv/guest_s390_toIR.c 2011-04-28 20:13:45 UTC (rev 2135)
@@ -308,8 +308,7 @@
/* Store the system call number in the pseudo register. */
stmt(IRStmt_Put(OFFSET_s390x_SYSNO, sysno));
- /* Store the current IA into guest_IP_AT_SYSCALL. libvex_ir.h says so.
- fixs390: As we do not use it, can we get rid of it ?? */
+ /* Store the current IA into guest_IP_AT_SYSCALL. libvex_ir.h says so. */
stmt(IRStmt_Put(OFFSET_s390x_IP_AT_SYSCALL, mkU64(guest_IA_curr_instr)));
/* It's important that all ArchRegs carry their up-to-date value
@@ -9174,7 +9173,6 @@
assign(new1, binop(op, mkexpr(old1), mkexpr(old2)));
/* Special case: xc is used to zero memory */
- /* fixs390: we also want an instrumentation time shortcut */
if (op == Iop_Xor8) {
store(mkexpr(addr1),
IRExpr_Mux0X(unop(Iop_1Uto8, binop(Iop_CmpEQ64, mkexpr(start1),
|
|
From: <sv...@va...> - 2011-04-28 18:48:14
|
Author: sewardj
Date: 2011-04-28 19:48:06 +0100 (Thu, 28 Apr 2011)
New Revision: 2134
Log:
s390x: Implement Ist_MBE
VEX IR provides the statement Ist_MBE which is used to implement memory
barriers (Imbe_Fence). We use this statement to implement serialization which
is similar.
Fixes #271385. (Florian Krohm, br...@ac...)
Modified:
trunk/priv/guest_s390_toIR.c
trunk/priv/host_s390_defs.c
trunk/priv/host_s390_defs.h
trunk/priv/host_s390_isel.c
Modified: trunk/priv/guest_s390_toIR.c
===================================================================
--- trunk/priv/guest_s390_toIR.c 2011-04-28 18:38:42 UTC (rev 2133)
+++ trunk/priv/guest_s390_toIR.c 2011-04-28 18:48:06 UTC (rev 2134)
@@ -3059,6 +3059,10 @@
{
IRTemp cond = newTemp(Ity_I32);
+ if (r2 == 0 && (r1 >= 14)) { /* serialization */
+ stmt(IRStmt_MBE(Imbe_Fence));
+ }
+
if ((r2 == 0) || (r1 == 0)) {
} else {
if (r1 == 15) {
Modified: trunk/priv/host_s390_defs.c
===================================================================
--- trunk/priv/host_s390_defs.c 2011-04-28 18:38:42 UTC (rev 2133)
+++ trunk/priv/host_s390_defs.c 2011-04-28 18:48:06 UTC (rev 2134)
@@ -699,6 +699,9 @@
addHRegUse(u, HRmRead, insn->variant.bfp128_unop.op_lo);
break;
+ case S390_INSN_MFENCE:
+ break;
+
default:
vpanic("s390_insn_get_reg_usage");
}
@@ -899,6 +902,9 @@
lookupHRegRemap(m, insn->variant.bfp128_unop.op_lo);
break;
+ case S390_INSN_MFENCE:
+ break;
+
default:
vpanic("s390_insn_map_regs");
}
@@ -4386,6 +4392,18 @@
}
+s390_insn *
+s390_insn_mfence(void)
+{
+ s390_insn *insn = LibVEX_Alloc(sizeof(s390_insn));
+
+ insn->tag = S390_INSN_MFENCE;
+ insn->size = 0; /* not needed */
+
+ return insn;
+}
+
+
/*---------------------------------------------------------------*/
/*--- Debug print ---*/
/*---------------------------------------------------------------*/
@@ -4797,6 +4815,10 @@
insn->variant.bfp128_unop.op_hi);
break;
+ case S390_INSN_MFENCE:
+ s390_sprintf(buf, "%M", "v-mfence");
+ return buf; /* avoid printing "size = ..." which is meaningless */
+
default: goto fail;
}
@@ -6999,6 +7021,13 @@
}
+static UChar *
+s390_insn_mfence_emit(UChar *buf, const s390_insn *insn)
+{
+ return s390_emit_BCR(buf, 0xF, 0x0);
+}
+
+
Int
emit_S390Instr(UChar *buf, Int nbuf, struct s390_insn *insn,
Bool mode64, void *dispatch)
@@ -7110,6 +7139,10 @@
end = s390_insn_bfp128_convert_from_emit(buf, insn);
break;
+ case S390_INSN_MFENCE:
+ end = s390_insn_mfence_emit(buf, insn);
+ break;
+
default:
vpanic("s390_insn_emit");
}
Modified: trunk/priv/host_s390_defs.h
===================================================================
--- trunk/priv/host_s390_defs.h 2011-04-28 18:38:42 UTC (rev 2133)
+++ trunk/priv/host_s390_defs.h 2011-04-28 18:48:06 UTC (rev 2134)
@@ -147,7 +147,8 @@
S390_INSN_BFP128_UNOP,
S390_INSN_BFP128_COMPARE,
S390_INSN_BFP128_CONVERT_TO,
- S390_INSN_BFP128_CONVERT_FROM
+ S390_INSN_BFP128_CONVERT_FROM,
+ S390_INSN_MFENCE
} s390_insn_tag;
@@ -451,6 +452,7 @@
s390_insn *s390_insn_bfp128_convert_from(UChar size, s390_bfp_unop_t,
HReg dst, HReg op_hi, HReg op_lo,
s390_round_t);
+s390_insn *s390_insn_mfence(void);
void s390_insn_map_regs(HRegRemap *, s390_insn *);
Bool s390_insn_is_reg_reg_move(const s390_insn *, HReg *, HReg *);
void s390_insn_get_reg_usage(HRegUsage *u, const s390_insn *);
Modified: trunk/priv/host_s390_isel.c
===================================================================
--- trunk/priv/host_s390_isel.c 2011-04-28 18:38:42 UTC (rev 2133)
+++ trunk/priv/host_s390_isel.c 2011-04-28 18:48:06 UTC (rev 2134)
@@ -2291,7 +2291,14 @@
}
/* --------- MEM FENCE --------- */
- case Ist_MBE: /* fixs390 later */
+ case Ist_MBE:
+ switch (stmt->Ist.MBE.event) {
+ case Imbe_Fence:
+ addInstr(env, s390_insn_mfence());
+ return;
+ default:
+ break;
+ }
break;
/* --------- Miscellaneous --------- */
|
|
From: <sv...@va...> - 2011-04-28 18:38:50
|
Author: sewardj
Date: 2011-04-28 19:38:42 +0100 (Thu, 28 Apr 2011)
New Revision: 2133
Log:
s390x: fix code confusion
Fix an enum-type mixup found by the IBM checker.
Fixes #271259. (Florian Krohm, br...@ac...)
Modified:
trunk/priv/host_s390_defs.c
trunk/priv/host_s390_defs.h
trunk/priv/host_s390_isel.c
Modified: trunk/priv/host_s390_defs.c
===================================================================
--- trunk/priv/host_s390_defs.c 2011-04-27 12:07:01 UTC (rev 2132)
+++ trunk/priv/host_s390_defs.c 2011-04-28 18:38:42 UTC (rev 2133)
@@ -4310,7 +4310,7 @@
s390_insn *
-s390_insn_bfp128_unop(UChar size, s390_bfp_binop_t tag, HReg dst_hi,
+s390_insn_bfp128_unop(UChar size, s390_bfp_unop_t tag, HReg dst_hi,
HReg dst_lo, HReg op_hi, HReg op_lo,
s390_round_t rounding_mode)
{
Modified: trunk/priv/host_s390_defs.h
===================================================================
--- trunk/priv/host_s390_defs.h 2011-04-27 12:07:01 UTC (rev 2132)
+++ trunk/priv/host_s390_defs.h 2011-04-28 18:38:42 UTC (rev 2133)
@@ -441,7 +441,7 @@
s390_insn *s390_insn_bfp128_binop(UChar size, s390_bfp_binop_t, HReg dst_hi,
HReg dst_lo, HReg op2_hi, HReg op2_lo,
s390_round_t);
-s390_insn *s390_insn_bfp128_unop(UChar size, s390_bfp_binop_t, HReg dst_hi,
+s390_insn *s390_insn_bfp128_unop(UChar size, s390_bfp_unop_t, HReg dst_hi,
HReg dst_lo, HReg op_hi, HReg op_lo,
s390_round_t);
s390_insn *s390_insn_bfp128_compare(UChar size, HReg dst, HReg op1_hi,
Modified: trunk/priv/host_s390_isel.c
===================================================================
--- trunk/priv/host_s390_isel.c 2011-04-27 12:07:01 UTC (rev 2132)
+++ trunk/priv/host_s390_isel.c 2011-04-28 18:38:42 UTC (rev 2133)
@@ -1474,7 +1474,7 @@
/* --------- BINARY OP --------- */
case Iex_Binop: {
HReg op_hi, op_lo, f12, f13, f14, f15;
- s390_bfp_binop_t bfpop;
+ s390_bfp_unop_t bfpop;
s390_round_t rounding_mode;
/* We use non-virtual registers as pairs (f13, f15) and (f12, f14)) */
|
|
From: <sv...@va...> - 2011-04-28 18:36:56
|
Author: bart
Date: 2011-04-28 19:36:49 +0100 (Thu, 28 Apr 2011)
New Revision: 11717
Log:
syswrap/Linux: trace ioctl() calls only once / do not report two-argument
ioctl() calls as an error. Patch provided by Mark Hills. Closes #272730.
Modified:
trunk/coregrind/m_syswrap/syswrap-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2011-04-28 14:58:15 UTC (rev 11716)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2011-04-28 18:36:49 UTC (rev 11717)
@@ -3769,9 +3769,6 @@
PRE(sys_ioctl)
{
*flags |= SfMayBlock;
- PRINT("sys_ioctl ( %ld, 0x%lx, %#lx )",ARG1,ARG2,ARG3);
- PRE_REG_READ3(long, "ioctl",
- unsigned int, fd, unsigned int, request, unsigned long, arg);
// We first handle the ones that don't use ARG3 (even as a
// scalar/non-pointer argument).
|
|
From: <sv...@va...> - 2011-04-28 14:58:24
|
Author: sewardj
Date: 2011-04-28 15:58:15 +0100 (Thu, 28 Apr 2011)
New Revision: 11716
Log:
Change the TT_FAST hash function for from "insn_address >> 2" to
"insn_address >> 1". The former is appropriate for ARM code, where
all insns are 4-sized and 4-aligned, but not for Thumb code, where the
minimum size and alignment is 2. The old scheme happened to work for
Thumb (indeed, any hash function would), but caused huge amounts of
conflict misses in the fast cache for some programs.
The change has been observed to reduce conflict misses by up to 100
times, and in some cases, improves performance significantly for Thumb
code. Performance of ARM code is unchanged or possibly a bit worse.
Modified:
trunk/coregrind/m_dispatch/dispatch-arm-linux.S
trunk/coregrind/pub_core_transtab_asm.h
Modified: trunk/coregrind/m_dispatch/dispatch-arm-linux.S
===================================================================
--- trunk/coregrind/m_dispatch/dispatch-arm-linux.S 2011-04-27 23:25:15 UTC (rev 11715)
+++ trunk/coregrind/m_dispatch/dispatch-arm-linux.S 2011-04-28 14:58:15 UTC (rev 11716)
@@ -99,7 +99,7 @@
/* try a fast lookup in the translation cache */
// r0 = next guest, r1,r2,r3 scratch
ldr r1, =VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
- and r2, r1, r0, LSR #2 // r2 = entry #
+ and r2, r1, r0, LSR #1 // r2 = entry #
ldr r1, =VG_(tt_fast) // r1 = &tt_fast[0]
add r1, r1, r2, LSL #3 // r1 = &tt_fast[entry#]
ldr r3, [r1, #0] /* .guest */
@@ -144,7 +144,7 @@
/* try a fast lookup in the translation cache */
// r0 = next guest, r1,r2,r3 scratch
ldr r1, =VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
- and r2, r1, r0, LSR #2 // r2 = entry #
+ and r2, r1, r0, LSR #1 // r2 = entry #
ldr r1, =VG_(tt_fast) // r1 = &tt_fast[0]
add r1, r1, r2, LSL #3 // r1 = &tt_fast[entry#]
ldr r3, [r1, #0] /* .guest */
Modified: trunk/coregrind/pub_core_transtab_asm.h
===================================================================
--- trunk/coregrind/pub_core_transtab_asm.h 2011-04-27 23:25:15 UTC (rev 11715)
+++ trunk/coregrind/pub_core_transtab_asm.h 2011-04-28 14:58:15 UTC (rev 11716)
@@ -54,12 +54,16 @@
/* This macro isn't usable in asm land; nevertheless this seems
like a good place to put it. */
+
#if defined(VGA_x86) || defined(VGA_amd64)
# define VG_TT_FAST_HASH(_addr) ((((UWord)(_addr)) ) & VG_TT_FAST_MASK)
-#elif defined(VGA_ppc32) || defined(VGA_ppc64) || defined(VGA_arm)
+
+#elif defined(VGA_s390x) || defined(VGA_arm)
+# define VG_TT_FAST_HASH(_addr) ((((UWord)(_addr)) >> 1) & VG_TT_FAST_MASK)
+
+#elif defined(VGA_ppc32) || defined(VGA_ppc64)
# define VG_TT_FAST_HASH(_addr) ((((UWord)(_addr)) >> 2) & VG_TT_FAST_MASK)
-#elif defined(VGA_s390x)
-# define VG_TT_FAST_HASH(_addr) ((((UWord)(_addr)) >> 1) & VG_TT_FAST_MASK)
+
#else
# error "VG_TT_FAST_HASH: unknown platform"
#endif
|
|
From: Bart V. A. <bva...@ac...> - 2011-04-28 08:24:58
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2011-04-28 02:47:34 EDT Ended at 2011-04-28 04:24:44 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 457 tests, 12 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) callgrind/tests/simwork-both (stdout) callgrind/tests/simwork-both (stderr) callgrind/tests/simwork-branch (stdout) callgrind/tests/simwork-branch (stderr) none/tests/empty-exe (stderr) none/tests/faultstatus (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Julian S. <js...@ac...> - 2011-04-28 07:43:31
|
Seems like a good idea. There's a kind-of functionality overlap
which you may not be aware of, though (?): VEX/test_main.c is
a program which does something similar, but has two different
features:
(1) it contains a very cut-down, ancient version of the instrumenter
used in memcheck/mc_translate.c, so you can play the same game,
but also check that the back end does a reasonable job on the
IR ops that are generated only by Memcheck (CmpNEZ*, Left*)
(2) it will process a whole stream of blocks, and optionally
can iterate each block as many times as required. This is
useful for profiling VEX.
It reads the ".orig" files, eg VEX/orig_x86/exit42.orig.
It's fragile and unmaintained and hacky, but it's sometimes
useful. A clean, more maintainable semi-equivalent would be
no bad thing. Not sure if (1) is worth keeping. (2) is
occasionally useful.
J
On Thursday, April 28, 2011, Florian Krohm wrote:
> I have been thinking about end-to-end unit-testing of the VEX
> translation pipeline. My motivation is to set up a test suite
> for s390x where I run a single insn (or a handful of them)
> through the VEX pipeline and make sure that
> (a) we don't assert
> (b) IR optimizations happen as expected
> (c) code generation takes advantage of insns available only at
> certain hwcaps levels
>
> So I've written a small program VEX/auxprogs/run-insns.c which
> reads a stream of encoded instructions from a file and pipes
> them through VEX without any instrumentations. For instance,
> if this is the input file:
>
> $ cat flogr
>
> A5 4F DE AD # R4 = 0xDEAD
> B9 83 00 14 # R1 = leftmost-bit(R4); R2 = R4 with leftmost-bit=0
> 00 00
>
> then
>
> run-insns --s390x --trace-flags=00000010 flogr will produce
>
> ------------------------ Register-allocated code ------------------------
>
> 0 v-loadi %r1,0xDEAD 8 bytes
> 1 v-store %r1,guest_r4 8 bytes
> 2 v-loadi %r1,48 8 bytes
> 3 v-store %r1,guest_r1 8 bytes
> 4 v-loadi %r1,0x5EAD 8 bytes
> 5 v-store %r1,guest_r2 8 bytes
> 6 v-loadi %r1,2 8 bytes
> 7 v-store %r1,guest_CC_OP 8 bytes
> 8 v-loadi %r1,0xDEAD 8 bytes
> 9 v-store %r1,guest_CC_DEP1 8 bytes
> 10 v-loadi %r1,0 8 bytes
> 11 v-store %r1,guest_CC_DEP2 8 bytes
> 12 v-loadi %r1,0 8 bytes
> 13 v-store %r1,guest_CC_NDEP 8 bytes
> 14 v-loadi %r1,8 8 bytes
> 15 v-store %r1,guest_IA 8 bytes
> 16 if (always) goto guest_r0 0 bytes
>
> I can easily verify that constant folding and propagation knocks
> down all the complexity that the initial IR had. Good.
> By using --trace-flags=00000001 I can study the generated code
> for inefficiencies, i.e. whether it uses instructions that are
> only available when certain hwcaps are present.
> So this is quite useful to build up a testsuite for various complex
> instructions.
>
> Essentially, run-insns.c sets up abi_info, arch_info, vex_control,
> and VexTranslateArgs based on command line flags given to it and
> then invokes VEX. The whole thing is extensible but works for s390x
> only, currently.
>
> The changes to VEX proper are minimal: two new members to vex_control,
> that's it. One to enable unit-testing and one to enable printing of
> symbolic names for guest registers in VCODE (instead of printing the
> amode). See above: guest_r1, guest_CC_OP etc.
>
> One thing I'm not exactly sure about is where to put the tests.
> I looked at VEX/test but did not understand how that is working.
> So I've added VEX/tests/s390x and put the tests there. Is that agreeable?
>
> Next, and more complex, is whether I can / should reuse the
> vg_regtest machinery. It seems to always want to invoke valgrind, but
> that would be overkill here. I did not look at vg_regtest in detail,
> yet, so comments with respect to its suitability would be welcome.
>
> Florian
>
> Attached is an initial work-in-progress patch.
|
|
From: Julian S. <js...@ac...> - 2011-04-28 07:31:52
|
> I believe this is the culprit. Rewrite this like so: > > HReg xT = iselVecExpr(env, e->Iex.Qop.arg2); /* I presume this is xT */ > HReg xA = iselVecExpr(env, e->Iex.Qop.arg3); > HReg xB = iselVecExpr(env, e->Iex.Qop.arg4); > set_FPU_rounding_mode( env, e->Iex.Qop.arg1 ); > dst = newVreg.... /* allocate a new Vreg here */ > addInstr(env, /* copy contents of xT to dst */); > addInstr(env, PPCInstr_VxQop(Pavfp_MADD, True, dst, xA, xB)); > return dst; > > That should do the trick. I agree. As you say, Maynard fell foul of the rule that says that you cannot (emit code to) modify a register returned by any of the isel*expr functions. As documented on comment above iselWordExpr_R. Maynard, look at how mk_iMOVds_RR is used in that file. Then make a vector equivalent of it and use that to do the copying. Also, have a look at isMove in host_ppc_defs.c: that is what the regalloc uses to identify these move instructions later, when it is trying to get rid of them. The reason for the rule is very simple. The instruction selectors carry around a mapping from IRTemp to virtual register, which holds the identity of the virtual register that holds the value for that IRTemp. This mapping lives in the ISelEnv that is passed everywhere. When we come to do instruction selection for an Iex_RdTmp (read of an IR temporary), no instructions are generated; instead we simply look up the IR temp in the mapping (via lookupIRTemp) and return the identity of the associated virtual register. That's simple, but it does mean that any later modification of the virtual register changes the value of the IR temporary, which can't happen (it's SSA) and so later uses of the IR temporary would "see" a different value, which is wrong. Hence the insistence on copying, plus machinery for removing copies when the copy marks the end of the live range of the source vreg and the beginning of the live range of the destination vreg. Plus .. this makes it way simpler to generate code for 2 address machines (x86, etc) since we can just indiscriminately copy values and assume the copies will disappear later. This is much easier than having to consider, everywhere in isel, whether an emitted instruction is going to overwrite a value in a register that will later be needed. J |
|
From: Florian K. <br...@ac...> - 2011-04-28 03:14:37
|
I have been thinking about end-to-end unit-testing of the VEX
translation pipeline. My motivation is to set up a test suite
for s390x where I run a single insn (or a handful of them)
through the VEX pipeline and make sure that
(a) we don't assert
(b) IR optimizations happen as expected
(c) code generation takes advantage of insns available only at
certain hwcaps levels
So I've written a small program VEX/auxprogs/run-insns.c which
reads a stream of encoded instructions from a file and pipes
them through VEX without any instrumentations. For instance,
if this is the input file:
$ cat flogr
A5 4F DE AD # R4 = 0xDEAD
B9 83 00 14 # R1 = leftmost-bit(R4); R2 = R4 with leftmost-bit=0
00 00
then
run-insns --s390x --trace-flags=00000010 flogr will produce
------------------------ Register-allocated code ------------------------
0 v-loadi %r1,0xDEAD 8 bytes
1 v-store %r1,guest_r4 8 bytes
2 v-loadi %r1,48 8 bytes
3 v-store %r1,guest_r1 8 bytes
4 v-loadi %r1,0x5EAD 8 bytes
5 v-store %r1,guest_r2 8 bytes
6 v-loadi %r1,2 8 bytes
7 v-store %r1,guest_CC_OP 8 bytes
8 v-loadi %r1,0xDEAD 8 bytes
9 v-store %r1,guest_CC_DEP1 8 bytes
10 v-loadi %r1,0 8 bytes
11 v-store %r1,guest_CC_DEP2 8 bytes
12 v-loadi %r1,0 8 bytes
13 v-store %r1,guest_CC_NDEP 8 bytes
14 v-loadi %r1,8 8 bytes
15 v-store %r1,guest_IA 8 bytes
16 if (always) goto guest_r0 0 bytes
I can easily verify that constant folding and propagation knocks
down all the complexity that the initial IR had. Good.
By using --trace-flags=00000001 I can study the generated code
for inefficiencies, i.e. whether it uses instructions that are
only available when certain hwcaps are present.
So this is quite useful to build up a testsuite for various complex
instructions.
Essentially, run-insns.c sets up abi_info, arch_info, vex_control,
and VexTranslateArgs based on command line flags given to it and
then invokes VEX. The whole thing is extensible but works for s390x
only, currently.
The changes to VEX proper are minimal: two new members to vex_control,
that's it. One to enable unit-testing and one to enable printing of
symbolic names for guest registers in VCODE (instead of printing the
amode). See above: guest_r1, guest_CC_OP etc.
One thing I'm not exactly sure about is where to put the tests.
I looked at VEX/test but did not understand how that is working.
So I've added VEX/tests/s390x and put the tests there. Is that agreeable?
Next, and more complex, is whether I can / should reuse the
vg_regtest machinery. It seems to always want to invoke valgrind, but
that would be overkill here. I did not look at vg_regtest in detail,
yet, so comments with respect to its suitability would be welcome.
Florian
Attached is an initial work-in-progress patch.
|
|
From: Tom H. <th...@cy...> - 2011-04-28 02:54:02
|
Nightly build on vauxhall ( x86_64, Fedora 14 ) Started at 2011-04-28 03:20:04 BST Ended at 2011-04-28 03:53:40 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 569 tests, 4 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/origin5-bz2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) drd/tests/pth_detached2 (stdout) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 569 tests, 4 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/origin5-bz2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Apr 28 03:36:35 2011 --- new.short Thu Apr 28 03:53:40 2011 *************** *** 8,10 **** ! == 569 tests, 4 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) --- 8,10 ---- ! == 569 tests, 4 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/linux/stack_switch (stderr) *************** *** 12,13 **** --- 12,14 ---- helgrind/tests/tc06_two_races_xml (stderr) + drd/tests/pth_detached2 (stdout) exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2011-04-28 02:39:22
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2011-04-28 03:10:04 BST Ended at 2011-04-28 03:38:59 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 573 tests, 3 stderr failures, 4 stdout failures, 0 post failures == none/tests/amd64/bug132918 (stdout) none/tests/amd64/fxtract (stdout) none/tests/amd64/sse4-64 (stdout) none/tests/x86/fxtract (stdout) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Florian K. <br...@ac...> - 2011-04-28 02:07:18
|
On 04/27/2011 08:19 PM, Maynard Johnson wrote:
> ------- host_ppc_isel.c ----------
> if (e->tag == Iex_Qop) {
> if (e->Iex.Qop.op == Iop_MAdd64Fx2) {
> HReg dst = iselVecExpr(env, e->Iex.Qop.arg2);
> HReg xA = iselVecExpr(env, e->Iex.Qop.arg3);
> HReg xB = iselVecExpr(env, e->Iex.Qop.arg4);
> set_FPU_rounding_mode( env, e->Iex.Qop.arg1 );
> addInstr(env, PPCInstr_VxQop(Pavfp_MADD, True, dst, xA, xB));
> return dst;
> }
> }
> ---------------------------------
I believe this is the culprit. Rewrite this like so:
HReg xT = iselVecExpr(env, e->Iex.Qop.arg2); /* I presume this is xT */
HReg xA = iselVecExpr(env, e->Iex.Qop.arg3);
HReg xB = iselVecExpr(env, e->Iex.Qop.arg4);
set_FPU_rounding_mode( env, e->Iex.Qop.arg1 );
dst = newVreg.... /* allocate a new Vreg here */
addInstr(env, /* copy contents of xT to dst */);
addInstr(env, PPCInstr_VxQop(Pavfp_MADD, True, dst, xA, xB));
return dst;
That should do the trick.
Florian
|
|
From: Maynard J. <may...@us...> - 2011-04-28 00:19:50
|
Julian Seward wrote:
> On Thursday, April 28, 2011, Florian Krohm wrote:
>> On 04/27/2011 06:40 PM, Maynard Johnson wrote:
>>> My "dst" register has the same value it did as when it was used as input.
>>
>> This sounds familiar. I think something like this happened to me once,
>> and the problem was in insn selection where my isel_int_expr_wrk was
>> returning a register that was modified before. And that's not allowed.
>> Perhaps that is what's happening. But I'm just guessing.
>
> Maynard needs to say whether he's talking about front end stuff
> (_toIR.c) or back end stuff (_isel.c). I can't guess from the
> original posting.
>
Here are some details to clarify the question . . .
In the frontend (guest_ppc_toIR.c):
---------------------
case 0x184: case 0x1A4: // xvmaddadp
{
DIP("xvmaddadp v%d,v%d,v%d\n", (UInt)XT, (UInt)XA, (UInt)XB);
putVSReg( XT,
qop( Iop_MAdd64Fx2,
rm,
getVSReg( XT ),
getVSReg( XA ),
getVSReg( XB ) ) );
break;
}
---------------------
The new operation is a "Vector multiply add double precision". All three registers are vector regs, each holding two double precision floating point input values. The arithmetic that's done is (XA * XB) + XT. Special rules apply to both the intermediate and final results such that I can't simply break the vector registers in two and operate on the constituent FPs with Iop_MulF64 and Iop_AddF64. So I defined Iop_MAdd64Fx2 and implemented the backend for this new Iop. So the backend looks like this:
------- host_ppc_isel.c ----------
if (e->tag == Iex_Qop) {
if (e->Iex.Qop.op == Iop_MAdd64Fx2) {
HReg dst = iselVecExpr(env, e->Iex.Qop.arg2);
HReg xA = iselVecExpr(env, e->Iex.Qop.arg3);
HReg xB = iselVecExpr(env, e->Iex.Qop.arg4);
set_FPU_rounding_mode( env, e->Iex.Qop.arg1 );
addInstr(env, PPCInstr_VxQop(Pavfp_MADD, True, dst, xA, xB));
return dst;
}
}
---------------------------------
------- host_ppc_defs.c ----------
case Pin_VxQopFP: {
UInt v_dst = vregNo(i->Pin.VxQopFP.xT);
UInt v_srcL = vregNo(i->Pin.VxQopFP.xA);
UInt v_srcR = vregNo(i->Pin.VxQopFP.xB);
if (i->Pin.VxQopFP.op == Pavfp_MADD) {
if (i->Pin.VxQopFP.d_prec)
p = mkFormVX3( p, 60, v_dst, v_srcL, v_srcR, 97 );
}
goto done;
}
---------------------------------
NOTE: Not shown above, but I also updated the "mapRegs" and getRegUsage" functions of host_ppc_defs.c.
When my testcase executes the xvmaddadp insn and prints out the XT register, it has the same value as its input value versus the expected output value. I know the xvmaddadp insn is being executed because I ran the testcase under valgrind with ' --trace-notbelow' and '--trace-flags=10000001' to show assembly code, and I see the xvmaddadp.
So I'm obviously missing something, but I just can't see what. Hopefully this is enough detail that someone can point me in the right direction. Thanks in advance for any help!
-Maynard
> J
|