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
(24) |
|
2
(50) |
3
(26) |
4
(17) |
5
(18) |
6
(20) |
7
(20) |
8
(16) |
|
9
(19) |
10
(11) |
11
(17) |
12
(17) |
13
(20) |
14
(18) |
15
(18) |
|
16
(15) |
17
(27) |
18
(22) |
19
(31) |
20
(19) |
21
(21) |
22
(14) |
|
23
(14) |
24
(18) |
25
(15) |
26
|
27
(1) |
28
|
29
(2) |
|
30
(16) |
|
|
|
|
|
|
|
From: Florian K. <br...@ac...> - 2012-09-29 17:50:36
|
On 09/21/2012 02:18 PM, Josef Weidendorfer wrote: > Am 21.09.2012 19:01, schrieb Florian Krohm: >> DATA_INSN_CACHE // combined data and insn cache > > The standard term here is "unified", ie. UNIFIED_CACHE ? > Hello Josef, I finally have a bit of time to look at this again. Sure, UNIFIED_CACHE sounds good. I read the cachegrind documentation. It mentions that for a machine with 3 levels of cache, the L3 cache will be used instead of L2. What about a machine with 4 cache levels such as the one below (s390). Should the L4 cache be used instead of L2 ? Florian L1 topology: separate data and instruction; private L1 cache line size data: 256 L1 cache line size insn: 256 L1 total cachesize data: 131072 L1 total cachesize insn: 65536 L1 set. assoc. data: 8 L1 set. assoc. insn: 4 L2 topology: unified data and instruction; private L2 cache line size: 256 L2 total cachesize: 1572864 L2 set. assoc. : 12 L3 topology: unified data and instruction; shared L3 cache line size: 256 L3 total cachesize: 25165824 L3 set. assoc. : 12 L4 topology: unified data and instruction; shared L4 cache line size: 256 L4 total cachesize: 201326592 L4 set. assoc. : 24 |
|
From: <sv...@va...> - 2012-09-29 17:12:46
|
florian 2012-09-29 18:05:46 +0100 (Sat, 29 Sep 2012)
New Revision: 2545
Log:
Change the return value of LibVEX_{Chain,UnChain,PatchProfInc}.
These functions now always return the address range that was
patched. Therefore, these functions no longer need knowledge
about I-cache coherency of the host system.
Modified files:
trunk/priv/host_amd64_defs.c
trunk/priv/host_s390_defs.c
trunk/priv/host_x86_defs.c
trunk/pub/libvex.h
Modified: trunk/priv/host_s390_defs.c (+9 -5)
===================================================================
--- trunk/priv/host_s390_defs.c 2012-09-21 01:06:14 +01:00 (rev 2544)
+++ trunk/priv/host_s390_defs.c 2012-09-29 18:05:46 +01:00 (rev 2545)
@@ -7643,7 +7643,7 @@
}
/* CODE points to the code sequence as generated by s390_tchain_load64.
- Change the loaded value to VALUE. Return pointer to the byte following
+ Change the loaded value to IMM64. Return pointer to the byte following
the patched code sequence. */
static UChar *
s390_tchain_patch_load64(UChar *code, ULong imm64)
@@ -8130,9 +8130,11 @@
s390_tchain_verify_load64(code_to_patch, S390_REGNO_TCHAIN_SCRATCH, 0);
- s390_tchain_patch_load64(code_to_patch, Ptr_to_ULong(location_of_counter));
+ UChar *p = s390_tchain_patch_load64(code_to_patch,
+ Ptr_to_ULong(location_of_counter));
- VexInvalRange vir = {0, 0};
+ UInt len = p - (UChar *)code_to_patch;
+ VexInvalRange vir = { (HWord)code_to_patch, len };
return vir;
}
@@ -8216,7 +8218,8 @@
/* There is not need to emit a BCR here, as it is already there. */
}
- VexInvalRange vir = {0, 0};
+ UInt len = p - (UChar *)place_to_chain;
+ VexInvalRange vir = { (HWord)place_to_chain, len };
return vir;
}
@@ -8286,7 +8289,8 @@
if (uses_short_form)
s390_emit_BCR(p, S390_CC_ALWAYS, S390_REGNO_TCHAIN_SCRATCH);
- VexInvalRange vir = {0, 0};
+ UInt len = p - (UChar *)place_to_unchain;
+ VexInvalRange vir = { (HWord)place_to_unchain, len };
return vir;
}
Modified: trunk/pub/libvex.h (+3 -5)
===================================================================
--- trunk/pub/libvex.h 2012-09-21 01:06:14 +01:00 (rev 2544)
+++ trunk/pub/libvex.h 2012-09-29 18:05:46 +01:00 (rev 2545)
@@ -699,14 +699,12 @@
/*--- Patch existing translations ---*/
/*-------------------------------------------------------*/
-/* Indicates a host address range for which callers to the functions
- below must request I-D cache syncing after the call. ::len == 0 is
- ambiguous -- it could mean either zero bytes or the entire address
- space, so we mean the former. */
+/* A host address range that was modified by the functions below.
+ Callers must request I-cache syncing after the call as appropriate. */
typedef
struct {
HWord start;
- HWord len;
+ HWord len; /* always > 0 */
}
VexInvalRange;
Modified: trunk/priv/host_x86_defs.c (+3 -3)
===================================================================
--- trunk/priv/host_x86_defs.c 2012-09-21 01:06:14 +01:00 (rev 2544)
+++ trunk/priv/host_x86_defs.c 2012-09-29 18:05:46 +01:00 (rev 2545)
@@ -3349,7 +3349,7 @@
/* sanity check on the delta -- top 32 are all 0 or all 1 */
delta >>= 32;
vassert(delta == 0LL || delta == -1LL);
- VexInvalRange vir = {0, 0};
+ VexInvalRange vir = { (HWord)place_to_chain, 7 };
return vir;
}
@@ -3392,7 +3392,7 @@
*(UInt*)(&p[1]) = (UInt)Ptr_to_ULong(disp_cp_chain_me);
p[5] = 0xFF;
p[6] = 0xD2;
- VexInvalRange vir = {0, 0};
+ VexInvalRange vir = { (HWord)place_to_unchain, 7 };
return vir;
}
@@ -3428,7 +3428,7 @@
p[10] = imm32 & 0xFF; imm32 >>= 8;
p[11] = imm32 & 0xFF; imm32 >>= 8;
p[12] = imm32 & 0xFF; imm32 >>= 8;
- VexInvalRange vir = {0, 0};
+ VexInvalRange vir = { (HWord)place_to_patch, 14 };
return vir;
}
Modified: trunk/priv/host_amd64_defs.c (+3 -3)
===================================================================
--- trunk/priv/host_amd64_defs.c 2012-09-21 01:06:14 +01:00 (rev 2544)
+++ trunk/priv/host_amd64_defs.c 2012-09-29 18:05:46 +01:00 (rev 2545)
@@ -3595,7 +3595,7 @@
*(ULong*)(&p[2]) = Ptr_to_ULong(place_to_jump_to);
p[12] = 0xE3;
}
- VexInvalRange vir = {0, 0};
+ VexInvalRange vir = { (HWord)place_to_chain, 13 };
return vir;
}
@@ -3659,7 +3659,7 @@
p[10] = 0x41;
p[11] = 0xFF;
p[12] = 0xD3;
- VexInvalRange vir = {0, 0};
+ VexInvalRange vir = { (HWord)place_to_unchain, 13 };
return vir;
}
@@ -3693,7 +3693,7 @@
p[7] = imm64 & 0xFF; imm64 >>= 8;
p[8] = imm64 & 0xFF; imm64 >>= 8;
p[9] = imm64 & 0xFF; imm64 >>= 8;
- VexInvalRange vir = {0, 0};
+ VexInvalRange vir = { (HWord)place_to_patch, 13 };
return vir;
}
|