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
(4) |
2
(1) |
3
|
|
4
|
5
(6) |
6
|
7
(7) |
8
(2) |
9
(1) |
10
(2) |
|
11
(4) |
12
(1) |
13
(4) |
14
(5) |
15
(2) |
16
(5) |
17
(2) |
|
18
(3) |
19
(12) |
20
(10) |
21
(3) |
22
(7) |
23
(4) |
24
(5) |
|
25
(3) |
26
(2) |
27
(1) |
28
|
29
(1) |
30
(1) |
|
|
From: Knapp, R. L <ras...@in...> - 2016-09-07 20:14:00
|
Hi all, I am working on this idea. I will let you know more when I have more information. Regards, -Rashawn -----Original Message----- From: Jeffrey Walton [mailto:nol...@gm...] Sent: Wednesday, September 07, 2016 1:09 PM To: Philippe Waroquiers <phi...@sk...> Cc: val...@li...; js...@ac...; Petar Jovanovic <mip...@gm...>; val...@li... Subject: Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry >> Can you make available, reliable, administrative-hassle-free remote >> access to a box that supports AVX-512? > Assuming there is an access to an AVX512 box, I can take in charge the > updates needed for valgrind gdbserver. > > Note that one admin hassle free way to provide such a box is for intel > to donate such a box to gcc compile farm (and maybe even better, to > host it). +1. I was thinking the same thing - host a farm or donate a couple of machines to the GCC compile farm. Jeff ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: <sv...@va...> - 2016-09-07 20:12:39
|
Author: philippe
Date: Wed Sep 7 21:12:30 2016
New Revision: 15945
Log:
Fix 199468 - Suppressions: stack size limited to 25 while --num-callers allows more frames
Nr of callers in a suppression entry had a smaller limit than the max
for --num-callers.
This means it was not possible to precisely suppress an error with a big
stack trace.
Also, --gen-suppressions was not providing the full stack trace of
the error in the generated suppressions.
Now, a suppression entry can have the same nr of callers as a backtrace.
Generated suppressions are generated with up to --num-callers callers.
This change has neglectible impact :
* memory: stack array of 500*2 words is declared, instead of 24*2 words
This array is declared on the interim stack (startup stack), which is
largely big enough.
* cpu : neglectible more cpu needed to read suppression entries
(to initialise the bigger stack array when reading a supp entry),
Apart of the above, no impact on performance (unless of course bigger
supp entries are really used).
Note that this does not impact the behaviour for existing suppression files.
Modified:
trunk/NEWS
trunk/coregrind/m_errormgr.c
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Wed Sep 7 21:12:30 2016
@@ -26,6 +26,11 @@
"nouserintercepts" can be any non-existing library name).
This new functionality is not implemented for darwin/macosx.
+* The maximum number of callers in a suppression entry is now equal to
+ the maximum size for --num-callers (500).
+ Note that --gen-suppressions=yes|all similarly generate suppression
+ containing up to --num-callers frames.
+
* New and modified GDB server monitor features:
- Valgrind's gdbserver now accepts the command 'catch syscall'.
@@ -58,6 +63,7 @@
where XXXXXX is the bug number as listed below.
191069 Exiting due to signal not reported in XML output
+199468 Suppressions: stack size limited to 25 while --num-callers allows more frames
212352 vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
278744 cvtps2pd with redundant RexW
303877 valgrind doesn't support compressed debuginfo sections.
Modified: trunk/coregrind/m_errormgr.c
==============================================================================
--- trunk/coregrind/m_errormgr.c (original)
+++ trunk/coregrind/m_errormgr.c Wed Sep 7 21:12:30 2016
@@ -195,8 +195,8 @@
}
CoreSuppKind;
-/* Max number of callers for context in a suppression. */
-#define VG_MAX_SUPP_CALLERS 24
+/* Max number of callers for context in a suppression is
+ VG_DEEPEST_BACKTRACE. */
/* For each caller specified for a suppression, record the nature of
the caller name. Not of interest to tools. */
@@ -410,8 +410,7 @@
// Print stack trace elements
UInt n_ips = VG_(get_ExeContext_n_ips)(ec);
vg_assert(n_ips > 0);
- if (n_ips > VG_MAX_SUPP_CALLERS)
- n_ips = VG_MAX_SUPP_CALLERS;
+ vg_assert(n_ips <= VG_DEEPEST_BACKTRACE);
VG_(apply_StackTrace)(printSuppForIp_nonXML,
text,
VG_(get_ExeContext_StackTrace)(ec),
@@ -1260,7 +1259,7 @@
HChar* tool_names;
HChar* supp_name;
const HChar* err_str = NULL;
- SuppLoc tmp_callers[VG_MAX_SUPP_CALLERS];
+ SuppLoc tmp_callers[VG_DEEPEST_BACKTRACE];
// Check it's not a directory.
if (VG_(is_dir)( filename )) {
@@ -1289,7 +1288,7 @@
supp->count = 0;
// Initialise temporary reading-in buffer.
- for (i = 0; i < VG_MAX_SUPP_CALLERS; i++) {
+ for (i = 0; i < VG_DEEPEST_BACKTRACE; i++) {
tmp_callers[i].ty = NoName;
tmp_callers[i].name_is_simple_str = False;
tmp_callers[i].name = NULL;
@@ -1391,7 +1390,7 @@
BOMB("missing stack trace");
}
}
- if (i == VG_MAX_SUPP_CALLERS)
+ if (i == VG_DEEPEST_BACKTRACE)
BOMB("too many callers in stack trace");
if (i > 0 && i >= VG_(clo_backtrace_size))
break;
|
|
From: Philippe W. <phi...@sk...> - 2016-09-07 19:33:21
|
On Wed, 2016-09-07 at 10:23 +0200, Julian Seward wrote: > Yes, I have seen AVX-512 looming on the horizon for a while. Yes, we > should support it. Dealing with AVX/AVX2 was a lot of work, and there is > not much AVX-512 available hardware out there, which may explain the > relative lack of activity so far. > > I would be willing to make the infrastructural changes in VEX and Valgrind > necessary to provide a framework in which we can incrementally add support > for individual instructions. That would be: addition of support for 512 > bit registers, changes in the front end instruction decoding framework, and > changes in the back end (if any required, possibly none). > > One problem is the lack of hardware. As I understand it, some but not > all Skylake CPUs support AVX-512. Having said that, if you are really > looking for a working implementation on Knights Landing then it would > be necessary to test any implementation both on Skylake+AVX512 and > Knights Landing. > > A good description of the instruction set is also necessary. Is that > publically available? > > Can you make available, reliable, administrative-hassle-free > remote access to a box that supports AVX-512? Assuming there is an access to an AVX512 box, I can take in charge the updates needed for valgrind gdbserver. Note that one admin hassle free way to provide such a box is for intel to donate such a box to gcc compile farm (and maybe even better, to host it). Philippe |
|
From: Carl E. L. <ce...@us...> - 2016-09-07 18:58:47
|
Valgrind Developers: The following patch was submitted to me by Will Schmidt. I have reviewed and tested the patch on PPC64 Power 7 and Power 8 platforms. The patch fixes the helgrind/tests/tc06_two_races_xml test failure on the Power 8 platforms. The test does not fail on Power 7. I created a bugzilla for the issue: https://bugs.kde.org/show_bug.cgi?id=368416 The patch touches architecture independent files the patch needs to be reviewed by the community. I have attached the patch below for your convenience. Please let me know if you see any issues with the patch. Thanks. Carl Love ------------------------------------------------------------------------------------------ Add a tc06_two_races_xml exp output for ppc64. This differs from the existing .exp in that does not contain the pthread_create_WRK entry frame. The non-xml version of this test passes because there is a filter that eliminates the pthread_create_WRK entry from that output. That was introduced in r13983, which added a filter to scrub out pthread_create_WRK from all of the outputs, and updated the .exp files to match. The additional exp file added here covers that same condition for the xml version of this test. I'll note that I did look at the code in and around pthread_create_WRK, in conjunction with the debug and comments from r13983. It looks like the _WRK stack frame is being reused rather than stacked upon. I suspect some part of branch-and-relink-to-noredir is not behaving quite as expected. That said, this rather simple update to the exp is sufficient and is not hiding anything I think is critical... --- helgrind/tests/Makefile.am | 2 helgrind/tests/tc06_two_races_xml.stderr.exp-ppc64 | 259 ++++++++++++++++++++ 2 files changed, 260 insertions(+), 1 deletion(-) create mode 100644 helgrind/tests/tc06_two_races_xml.stderr.exp-ppc64 diff --git a/helgrind/tests/Makefile.am b/helgrind/tests/Makefile.am index 8a0d6e6..a666158 100644 --- a/helgrind/tests/Makefile.am +++ b/helgrind/tests/Makefile.am @@ -68,7 +68,7 @@ EXTRA_DIST = \ tc06_two_races.vgtest tc06_two_races.stdout.exp \ tc06_two_races.stderr.exp \ tc06_two_races_xml.vgtest tc06_two_races_xml.stdout.exp \ - tc06_two_races_xml.stderr.exp \ + tc06_two_races_xml.stderr.exp tc06_two_races_xml.stderr.exp-ppc64 \ tc07_hbl1.vgtest tc07_hbl1.stdout.exp tc07_hbl1.stderr.exp \ tc08_hbl2.vgtest tc08_hbl2.stdout.exp tc08_hbl2.stderr.exp \ tc09_bad_unlock.vgtest tc09_bad_unlock.stdout.exp \ diff --git a/helgrind/tests/tc06_two_races_xml.stderr.exp-ppc64 b/helgrind/tests/tc06_two_races_xml.stderr.exp-ppc64 new file mode 100644 index 0000000..a442a28 --- /dev/null +++ b/helgrind/tests/tc06_two_races_xml.stderr.exp-ppc64 @@ -0,0 +1,259 @@ +<?xml version="1.0"?> + +<valgrindoutput> + +<protocolversion>4</protocolversion> +<protocoltool>helgrind</protocoltool> + +<preamble> + <line>Helgrind, a thread error detector</line> + <line>Copyright (C) XXXX-YYYY, and GNU GPL'd, by OpenWorks LLP et al.</line> + <line>Using Valgrind-X.Y.X and LibVEX; rerun with -h for copyright info</line> + <line>Command: ./tc06_two_races</line> +</preamble> + +<pid>...</pid> +<ppid>...</ppid> +<tool>helgrind</tool> + +<args> + <vargv> + <exe>...</exe> + <arg>--command-line-only=yes</arg> + <arg>--memcheck:leak-check=no</arg> + <arg>--tool=helgrind</arg> + <arg>--read-var-info=yes</arg> + <arg>--xml=yes</arg> + <arg>--xml-fd=2</arg> + <arg>--log-file=/dev/null</arg> + </vargv> + <argv> + <exe>...</exe> + </argv> +</args> + +<status> + <state>RUNNING</state> + <time>...</time> +</status> + +<announcethread> + <hthreadid>1</hthreadid> + <isrootthread></isrootthread> +</announcethread> + +<announcethread> + <hthreadid>2</hthreadid> + <stack> + <frame>...</frame> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>pthread_create</fn> + <dir>...</dir> + <file>hg_intercepts.c</file> + <line>...</line> + </frame> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>main</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>26</line> + </frame> + </stack> +</announcethread> + +<error> + <unique>...</unique> + <tid>...</tid> + <kind>Race</kind> + <xwhat> + <text>Possible data race during read of size 4 at 0x........ by thread #x</text> + <hthreadid>1</hthreadid> + </xwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>main</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>31</line> + </frame> + </stack> + <xauxwhat> + <text>This conflicts with a previous write of size 4 by thread #x</text> + <hthreadid>2</hthreadid> + </xauxwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>child_fn</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>14</line> + </frame> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>mythread_wrapper</fn> + <dir>...</dir> + <file>hg_intercepts.c</file> + <line>...</line> + </frame> + <frame>...</frame> + </stack> + <auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat> + <xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>9</line> </xauxwhat> +</error> + +<error> + <unique>...</unique> + <tid>...</tid> + <kind>Race</kind> + <xwhat> + <text>Possible data race during write of size 4 at 0x........ by thread #x</text> + <hthreadid>1</hthreadid> + </xwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>main</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>31</line> + </frame> + </stack> + <xauxwhat> + <text>This conflicts with a previous write of size 4 by thread #x</text> + <hthreadid>2</hthreadid> + </xauxwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>child_fn</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>14</line> + </frame> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>mythread_wrapper</fn> + <dir>...</dir> + <file>hg_intercepts.c</file> + <line>...</line> + </frame> + <frame>...</frame> + </stack> + <auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat> + <xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>9</line> </xauxwhat> +</error> + +<error> + <unique>...</unique> + <tid>...</tid> + <kind>Race</kind> + <xwhat> + <text>Possible data race during read of size 4 at 0x........ by thread #x</text> + <hthreadid>1</hthreadid> + </xwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>main</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>35</line> + </frame> + </stack> + <xauxwhat> + <text>This conflicts with a previous write of size 4 by thread #x</text> + <hthreadid>2</hthreadid> + </xauxwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>child_fn</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>18</line> + </frame> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>mythread_wrapper</fn> + <dir>...</dir> + <file>hg_intercepts.c</file> + <line>...</line> + </frame> + <frame>...</frame> + </stack> + <auxwhat>Location 0x........ is 0 bytes inside global var "unprot2"</auxwhat> + <xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>9</line> </xauxwhat> +</error> + +<error> + <unique>...</unique> + <tid>...</tid> + <kind>Race</kind> + <xwhat> + <text>Possible data race during write of size 4 at 0x........ by thread #x</text> + <hthreadid>1</hthreadid> + </xwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>main</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>35</line> + </frame> + </stack> + <xauxwhat> + <text>This conflicts with a previous write of size 4 by thread #x</text> + <hthreadid>2</hthreadid> + </xauxwhat> + <stack> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>child_fn</fn> + <dir>...</dir> + <file>tc06_two_races.c</file> + <line>18</line> + </frame> + <frame> + <ip>0x........</ip> + <obj>...</obj> + <fn>mythread_wrapper</fn> + <dir>...</dir> + <file>hg_intercepts.c</file> + <line>...</line> + </frame> + <frame>...</frame> + </stack> + <auxwhat>Location 0x........ is 0 bytes inside global var "unprot2"</auxwhat> + <xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>9</line> </xauxwhat> +</error> + + +<status> + <state>FINISHED</state> + <time>...</time> +</status> + +<errorcounts>...</errorcounts> + +<suppcounts>...</suppcounts> + +</valgrindoutput> + |
|
From: Carl E. L. <ce...@us...> - 2016-09-07 18:36:29
|
Valgrind Developers: The following patch was submitted to me by Will Schmidt to fix an issue with the Power Altivec configure test. I have created a bugzilla for it, https://bugs.kde.org/show_bug.cgi?id=368412 I have tested the patch on PPC and it seems fine. Since this patch touches an arch independent file it needs to be reviewed and tested by the other platform developers. Please let us know if you find any issues with the patch. It is a small patch, I have attached it below for your convenience. Carl Love ----------------------------------------------------------------------------------------- An earlier change introduced a think-o in the altivec capability check, allowing a false positive if the compiler supported altivec but the hardware did not. --- configure.ac | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index dd4fcb9..62faf4b 100644 --- a/configure.ac +++ b/configure.ac @@ -1379,12 +1379,13 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ ]])], [ ac_have_altivec=yes AC_MSG_RESULT([yes]) -AC_DEFINE([HAS_ALTIVEC], 1, +AC_DEFINE([COMPILER_SUPPORTS_ALTIVEC], 1, [Define to 1 if gcc/as can do Altivec.]) ], [ ac_have_altivec=no AC_MSG_RESULT([no]) ]) + CFLAGS=$safe_CFLAGS AM_CONDITIONAL([HAS_ALTIVEC], [test x$ac_have_altivec = xyes \ -a x$HWCAP_HAS_ALTIVEC = xyes]) |
|
From: John R. <jr...@bi...> - 2016-09-07 13:35:28
|
> A good description of the instruction set is also necessary. http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf |
|
From: Julian S. <js...@ac...> - 2016-09-07 08:23:40
|
Yes, I have seen AVX-512 looming on the horizon for a while. Yes, we should support it. Dealing with AVX/AVX2 was a lot of work, and there is not much AVX-512 available hardware out there, which may explain the relative lack of activity so far. I would be willing to make the infrastructural changes in VEX and Valgrind necessary to provide a framework in which we can incrementally add support for individual instructions. That would be: addition of support for 512 bit registers, changes in the front end instruction decoding framework, and changes in the back end (if any required, possibly none). One problem is the lack of hardware. As I understand it, some but not all Skylake CPUs support AVX-512. Having said that, if you are really looking for a working implementation on Knights Landing then it would be necessary to test any implementation both on Skylake+AVX512 and Knights Landing. A good description of the instruction set is also necessary. Is that publically available? Can you make available, reliable, administrative-hassle-free remote access to a box that supports AVX-512? J > -----Original Message----- > From: Petar Jovanovic [mailto:mip...@gm...] > Sent: Monday, September 05, 2016 11:48 AM > To: Jeff Hammond <jef...@gm...> > Cc: val...@li...; val...@li...; Mark Wielaard <mj...@re...> > Subject: Re: [Valgrind-developers] [Valgrind-users] AVX-512 support inquiry > > On Mon, Sep 5, 2016 at 6:31 PM, Jeff Hammond <jef...@gm...> wrote: >> >> It would be really valuable to a number of HPC programmers. Many DOE >> labs use it heavily. I wish I could help implement but I don't have >> the relevant skills. >> > > It may be worth to open a bug at kde and track future discussion there. |