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
|
2
|
3
(1) |
4
(1) |
5
|
6
(1) |
7
|
|
8
|
9
(1) |
10
(4) |
11
(3) |
12
(6) |
13
(13) |
14
(1) |
|
15
(1) |
16
(3) |
17
|
18
(1) |
19
(3) |
20
(7) |
21
(5) |
|
22
|
23
(1) |
24
|
25
(3) |
26
|
27
(3) |
28
|
|
29
(1) |
30
(1) |
31
(5) |
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2017-01-13 22:03:18
|
Using SETI (Search Extra Tile-gx Information) I tried to find some recent news about tile-gx, such as a newer version of the instruction set, or new processor models or whatever indicating a sign of active development life. I find nothing. To the contrary, what I can find is that the tile-gx architecture is being replaced by tile-mx, which is an ARM based chip. See a.o http://www.mellanox.com/repository/solutions/tile-scm/ and http://www.bdti.com/InsideDSP/2015/03/03/EZchip and various other things such as ezchip roadmap. So, no developer, no user, no company person telling anything, and public information telling the chip will be replaced. So, it looks clear that tile-gx will have to be removed sooner or later. IMO, sooner is better: I spent some effort even very recently on the tile-gx files (as part of a factorisation effort) and it looks like this (evening/week-end) effort was just spent for nothing, while some real users have to wait because their wishes are just put in my TODO list. The above is some additional info for the discussion we can have at FOSDEM2017 valgrind BoF. Maybe we will receive some information from Mellanox before FOSDEM in the meantime. But with the current info, it looks doubtful anybody wants to spend any more effort on maintaining this. Philippe On Fri, 2017-01-13 at 21:59 +0100, Julian Seward wrote: > That's not a fair comparison. The Solaris port has a very active > maintainer and (presumably) also has users. By comparison the Tilegx > port has shown no signs of life for a considerable period of time, > despite attempts by more than one person here to contact both maintainers > and users. In my view it is valid to discuss whether we should continue > to have the Tilegx port in the tree. > > J > > On 13/01/17 21:43, Irek Szczesniak wrote: > > OK, next is to remove the Solaris port of valgrind. OS was > > discontinued, Oracle does not respond to emails and there is no > > emulator. > > > > Please remove. > > > > Irek > > > > On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@iv...> wrote: > >> > >> > >> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers > >> <phi...@sk...>: > >>> > >>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote: > >>>> On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...> > >>>> wrote: > >>>>> On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers > >>>>> <phi...@sk...> wrote: > >>>>>> No sign of any tilegx user or developer activity since something like > >>>>>> one year. > >>>>>> No reply received for question in > >>>>>> https://sourceforge.net/p/valgrind/mailman/message/35566192/ > >>>>>> > >>>>>> Is there any tilegx user or developer still active ? > >>>>>> Should we consider this platform as dead ? > >>>>>> > >>>>> I have exchanged a few emails with Tilera/Mellanox compiler enigneers, > >>>>> and they say they cannot take care of TileGx port in Valgrind for the > >>>>> time being. > >>>> > >>>> Is there any emulator or other way we can use to test changes ? I > >>>> don't like seeing such a port just disappear... > >>> Well, if there is > >>> no known users, > >>> and no (original) developer doing maintenance > >>> and no reply from (original) developers to simple questions > >>> and no access to a system to test/compile > >>> and no nightly build > >>> and no tests in SVN > >>> and no emulator > >>> then IMO, this platform is a candidate to remove. > >>> as just keeping this compiling forever for no reason will > >>> at the end cost more than just removing it. > >> > >> > >> Agreed here. Although there are regtests under none/tests/tilegx there is no > >> way > >> to run them without any access to the machine or emulator. > >> I. > >> > >> ------------------------------------------------------------------------------ > >> Developer Access Program for Intel Xeon Phi Processors > >> Access to Intel Xeon Phi processor-based developer platforms. > >> With one year of Intel Parallel Studio XE. > >> Training and support from Colfax. > >> Order your platform today. http://sdm.link/xeonphi > >> _______________________________________________ > >> Valgrind-developers mailing list > >> Val...@li... > >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > >> > > > > > > > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Ivo R. <iv...@iv...> - 2017-01-13 21:31:58
|
2017-01-13 22:27 GMT+01:00 Dan Shelton <dan...@gm...>: > On 13 January 2017 at 21:59, Julian Seward <js...@ac...> wrote: > > > > That's not a fair comparison. The Solaris port has a very active > > maintainer and (presumably) also has users. > > Well, given that Mr Irek was part of the Opensolaris community I THINK > he was applying sarcasm and a large grain or whole mine of salt to the > situation. > > Also, even that Solaris is now dead, not only per > http://www.sunhelp.org/ but by the virtue of Oracle having laid off > more than 150 people of the core os team(!!!!!!), there is still > Illumos. > The information at sunhelp.org is heavily outdated (from 1st December 2016). Since then, a lot has happened. Have a look at the source cited at sunhelp.org and you will find much more fresh information which brings this whole situation into reality again. I. |
|
From: Dan S. <dan...@gm...> - 2017-01-13 21:27:57
|
On 13 January 2017 at 21:59, Julian Seward <js...@ac...> wrote: > > That's not a fair comparison. The Solaris port has a very active > maintainer and (presumably) also has users. Well, given that Mr Irek was part of the Opensolaris community I THINK he was applying sarcasm and a large grain or whole mine of salt to the situation. Also, even that Solaris is now dead, not only per http://www.sunhelp.org/ but by the virtue of Oracle having laid off more than 150 people of the core os team(!!!!!!), there is still Illumos. > By comparison the Tilegx > port has shown no signs of life for a considerable period of time, > despite attempts by more than one person here to contact both maintainers > and users. In my view it is valid to discuss whether we should continue > to have the Tilegx port in the tree. Who exactly was contacted? Oracle never bothered to comment on the Solaris port, yet valgrind has that port. Maybe the wrong people were contacted? Dan |
|
From: Julian S. <js...@ac...> - 2017-01-13 21:18:29
|
That's not a fair comparison. The Solaris port has a very active maintainer and (presumably) also has users. By comparison the Tilegx port has shown no signs of life for a considerable period of time, despite attempts by more than one person here to contact both maintainers and users. In my view it is valid to discuss whether we should continue to have the Tilegx port in the tree. J On 13/01/17 21:43, Irek Szczesniak wrote: > OK, next is to remove the Solaris port of valgrind. OS was > discontinued, Oracle does not respond to emails and there is no > emulator. > > Please remove. > > Irek > > On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@iv...> wrote: >> >> >> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers >> <phi...@sk...>: >>> >>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote: >>>> On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...> >>>> wrote: >>>>> On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers >>>>> <phi...@sk...> wrote: >>>>>> No sign of any tilegx user or developer activity since something like >>>>>> one year. >>>>>> No reply received for question in >>>>>> https://sourceforge.net/p/valgrind/mailman/message/35566192/ >>>>>> >>>>>> Is there any tilegx user or developer still active ? >>>>>> Should we consider this platform as dead ? >>>>>> >>>>> I have exchanged a few emails with Tilera/Mellanox compiler enigneers, >>>>> and they say they cannot take care of TileGx port in Valgrind for the >>>>> time being. >>>> >>>> Is there any emulator or other way we can use to test changes ? I >>>> don't like seeing such a port just disappear... >>> Well, if there is >>> no known users, >>> and no (original) developer doing maintenance >>> and no reply from (original) developers to simple questions >>> and no access to a system to test/compile >>> and no nightly build >>> and no tests in SVN >>> and no emulator >>> then IMO, this platform is a candidate to remove. >>> as just keeping this compiling forever for no reason will >>> at the end cost more than just removing it. >> >> >> Agreed here. Although there are regtests under none/tests/tilegx there is no >> way >> to run them without any access to the machine or emulator. >> I. >> >> ------------------------------------------------------------------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today. http://sdm.link/xeonphi >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > > > |
|
From: Ivo R. <iv...@iv...> - 2017-01-13 21:11:19
|
2017-01-13 21:43 GMT+01:00 Irek Szczesniak <isz...@gm...>: > OK, next is to remove the Solaris port of valgrind. OS was > discontinued, Oracle does not respond to emails and there is no > emulator. You can say remove OS X port of Valgrind as well in this manner. Prove your statements. Who says "[Solaris] OS is discontinued"? If you are running an x86 machine, an "emulator" is right on your machine - get x86/Solaris template for VirtualBox [1]. What are your Valgrind contributions in general which give you a position to say "remove something"? I. [1] http://www.oracle.com/technetwork/server-storage/solaris11/downloads/vm- templates-2245495.html |
|
From: Mark W. <mj...@re...> - 2017-01-13 21:10:09
|
On Fri, Jan 13, 2017 at 09:43:07PM +0100, Irek Szczesniak wrote: > OK, next is to remove the Solaris port of valgrind. OS was > discontinued, Oracle does not respond to emails and there is no > emulator. > > Please remove. You message is inappropriate in this thread. There are no issues with the valgrind solaris port. It is maintained. Reported bugs get fixed. Ivo is one of the most active valgrind developers. And he always makes sure other platforms benefit from his work. Please take your solaris/oracle rants somewhere else. Thanks, Mark |
|
From: Irek S. <isz...@gm...> - 2017-01-13 20:43:14
|
OK, next is to remove the Solaris port of valgrind. OS was discontinued, Oracle does not respond to emails and there is no emulator. Please remove. Irek On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@iv...> wrote: > > > 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers > <phi...@sk...>: >> >> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote: >> > On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...> >> > wrote: >> > > On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers >> > > <phi...@sk...> wrote: >> > >> No sign of any tilegx user or developer activity since something like >> > >> one year. >> > >> No reply received for question in >> > >> https://sourceforge.net/p/valgrind/mailman/message/35566192/ >> > >> >> > >> Is there any tilegx user or developer still active ? >> > >> Should we consider this platform as dead ? >> > >> >> > > I have exchanged a few emails with Tilera/Mellanox compiler enigneers, >> > > and they say they cannot take care of TileGx port in Valgrind for the >> > > time being. >> > >> > Is there any emulator or other way we can use to test changes ? I >> > don't like seeing such a port just disappear... >> Well, if there is >> no known users, >> and no (original) developer doing maintenance >> and no reply from (original) developers to simple questions >> and no access to a system to test/compile >> and no nightly build >> and no tests in SVN >> and no emulator >> then IMO, this platform is a candidate to remove. >> as just keeping this compiling forever for no reason will >> at the end cost more than just removing it. > > > Agreed here. Although there are regtests under none/tests/tilegx there is no > way > to run them without any access to the machine or emulator. > I. > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > -- Irek |
|
From: <pa...@fr...> - 2017-01-13 18:33:07
|
----- Original Message ----- > No sign of any tilegx user or developer activity since something like > one year. > No reply received for question in > https://sourceforge.net/p/valgrind/mailman/message/35566192/ > > Is there any tilegx user or developer still active ? > Should we consider this platform as dead ? > > Philippe Hi Perhaps related to this, the parent company of Tilera, EZchip, was acquired by Mellanox about a year ago: http://www.mellanox.com/page/press_release_item?id=1681 A+ Paul |
|
From: <sv...@va...> - 2017-01-13 18:02:50
|
Author: sewardj
Date: Fri Jan 13 18:02:38 2017
New Revision: 16202
Log:
Add support for Iop_MaxNumF64, Iop_MinNumF64, Iop_MaxNumF32 and
Iop_MinNumF32, as introduced in vex r3293.
Modified:
trunk/memcheck/mc_translate.c
trunk/memcheck/tests/vbit-test/irops.c
Modified: trunk/memcheck/mc_translate.c
==============================================================================
--- trunk/memcheck/mc_translate.c (original)
+++ trunk/memcheck/mc_translate.c Fri Jan 13 18:02:38 2017
@@ -1611,6 +1611,14 @@
return at;
}
+ /* I32 x I32 -> I32 */
+ if (t1 == Ity_I32 && t2 == Ity_I32 && finalVty == Ity_I32) {
+ if (0) VG_(printf)("mkLazy2: I32 x I32 -> I32\n");
+ at = mkUifU(mce, Ity_I32, va1, va2);
+ at = mkPCastTo(mce, Ity_I32, at);
+ return at;
+ }
+
if (0) {
VG_(printf)("mkLazy2 ");
ppIRType(t1);
@@ -3942,6 +3950,16 @@
case Iop_CmpExpD128:
return mkLazy2(mce, Ity_I32, vatom1, vatom2);
+ case Iop_MaxNumF32:
+ case Iop_MinNumF32:
+ /* F32 x F32 -> F32 */
+ return mkLazy2(mce, Ity_I32, vatom1, vatom2);
+
+ case Iop_MaxNumF64:
+ case Iop_MinNumF64:
+ /* F64 x F64 -> F64 */
+ return mkLazy2(mce, Ity_I64, vatom1, vatom2);
+
/* non-FP after here */
case Iop_DivModU64to32:
Modified: trunk/memcheck/tests/vbit-test/irops.c
==============================================================================
--- trunk/memcheck/tests/vbit-test/irops.c (original)
+++ trunk/memcheck/tests/vbit-test/irops.c Fri Jan 13 18:02:38 2017
@@ -295,6 +295,12 @@
{ DEFOP(Iop_RecpExpF64, UNDEF_UNKNOWN), },
{ DEFOP(Iop_RecpExpF32, UNDEF_UNKNOWN), },
+ /* --------- Possibly required by IEEE 754-2008. --------- */
+ { DEFOP(Iop_MaxNumF64, UNDEF_ALL), .arm = 1 },
+ { DEFOP(Iop_MinNumF64, UNDEF_ALL), .arm = 1 },
+ { DEFOP(Iop_MaxNumF32, UNDEF_ALL), .arm = 1 },
+ { DEFOP(Iop_MinNumF32, UNDEF_ALL), .arm = 1 },
+
/* ------------------ 16-bit scalar FP ------------------ */
{ DEFOP(Iop_F16toF64, UNDEF_ALL), .arm64 = 1 },
{ DEFOP(Iop_F64toF16, UNDEF_ALL), .arm64 = 1 },
|
|
From: <sv...@va...> - 2017-01-13 17:59:05
|
Author: sewardj
Date: Fri Jan 13 17:58:57 2017
New Revision: 3293
Log:
Implement
V{MIN,MAX}NM.F64 Dd, Dn, Dm
V{MIN,MAX}NM.F32 Sd, Sn, Sm
Modified:
trunk/priv/guest_arm_toIR.c
trunk/priv/host_arm_defs.c
trunk/priv/host_arm_defs.h
trunk/priv/host_arm_isel.c
trunk/priv/ir_defs.c
trunk/pub/libvex_ir.h
Modified: trunk/priv/guest_arm_toIR.c
==============================================================================
--- trunk/priv/guest_arm_toIR.c (original)
+++ trunk/priv/guest_arm_toIR.c Fri Jan 13 17:58:57 2017
@@ -13665,6 +13665,50 @@
return True;
}
+ /* ----------- V{MAX,MIN}NM{.F64 d_d_d, .F32 s_s_s} ----------- */
+ /* 31 27 22 21 19 15 11 8 7 6 5 4 3
+ 1111 11101 D 00 Vn Vd 101 1 N op M 0 Vm V{MIN,MAX}NM.F64 Dd, Dn, Dm
+ 1111 11101 D 00 Vn Vd 101 0 N op M 0 Vm V{MIN,MAX}NM.F32 Sd, Sn, Sm
+
+ ARM encoding is in NV space.
+ In Thumb mode, we must not be in an IT block.
+ */
+ if (INSN(31,23) == BITS9(1,1,1,1,1,1,1,0,1) && INSN(21,20) == BITS2(0,0)
+ && INSN(11,9) == BITS3(1,0,1) && INSN(4,4) == 0) {
+ UInt bit_D = INSN(22,22);
+ UInt fld_Vn = INSN(19,16);
+ UInt fld_Vd = INSN(15,12);
+ Bool isF64 = INSN(8,8) == 1;
+ UInt bit_N = INSN(7,7);
+ Bool isMAX = INSN(6,6) == 0;
+ UInt bit_M = INSN(5,5);
+ UInt fld_Vm = INSN(3,0);
+
+ UInt dd = isF64 ? ((bit_D << 4) | fld_Vd) : ((fld_Vd << 1) | bit_D);
+ UInt nn = isF64 ? ((bit_N << 4) | fld_Vn) : ((fld_Vn << 1) | bit_N);
+ UInt mm = isF64 ? ((bit_M << 4) | fld_Vm) : ((fld_Vm << 1) | bit_M);
+
+ if (isT) {
+ gen_SIGILL_T_if_in_ITBlock(old_itstate, new_itstate);
+ }
+ /* In ARM mode, this is statically unconditional. In Thumb mode,
+ this must be dynamically unconditional, and we've SIGILLd if not.
+ In either case we can create unconditional IR. */
+
+ IROp op = isF64 ? (isMAX ? Iop_MaxNumF64 : Iop_MinNumF64)
+ : (isMAX ? Iop_MaxNumF32 : Iop_MinNumF32);
+ IRExpr* srcN = (isF64 ? llGetDReg : llGetFReg)(nn);
+ IRExpr* srcM = (isF64 ? llGetDReg : llGetFReg)(mm);
+ IRExpr* res = binop(op, srcN, srcM);
+ (isF64 ? llPutDReg : llPutFReg)(dd, res);
+
+ UChar rch = isF64 ? 'd' : 'f';
+ DIP("v%snm.%s %c%u, %c%u, %c%u\n",
+ isMAX ? "max" : "min", isF64 ? "f64" : "f32",
+ rch, dd, rch, nn, rch, mm);
+ return True;
+ }
+
/* ---------- Doesn't match anything. ---------- */
return False;
Modified: trunk/priv/host_arm_defs.c
==============================================================================
--- trunk/priv/host_arm_defs.c (original)
+++ trunk/priv/host_arm_defs.c Fri Jan 13 17:58:57 2017
@@ -1374,6 +1374,18 @@
i->ARMin.VRIntR.src = src;
return i;
}
+ARMInstr* ARMInstr_VMinMaxNum ( Bool isF64, Bool isMax,
+ HReg dst, HReg srcL, HReg srcR )
+{
+ ARMInstr* i = LibVEX_Alloc_inline(sizeof(ARMInstr));
+ i->tag = ARMin_VMinMaxNum;
+ i->ARMin.VMinMaxNum.isF64 = isF64;
+ i->ARMin.VMinMaxNum.isMax = isMax;
+ i->ARMin.VMinMaxNum.dst = dst ;
+ i->ARMin.VMinMaxNum.srcL = srcL;
+ i->ARMin.VMinMaxNum.srcR = srcR;
+ return i;
+}
ARMInstr* ARMInstr_FPSCR ( Bool toFPSCR, HReg iReg ) {
ARMInstr* i = LibVEX_Alloc_inline(sizeof(ARMInstr));
i->tag = ARMin_FPSCR;
@@ -1890,6 +1902,17 @@
ppHRegARM(i->ARMin.VRIntR.src);
return;
}
+ case ARMin_VMinMaxNum: {
+ const HChar* sz = i->ARMin.VMinMaxNum.isF64 ? "f64" : "f32";
+ const HChar* nm = i->ARMin.VMinMaxNum.isMax ? "vmaxnm" : "vminnm";
+ vex_printf("%s.%s ", nm, sz);
+ ppHRegARM(i->ARMin.VMinMaxNum.dst);
+ vex_printf(", ");
+ ppHRegARM(i->ARMin.VMinMaxNum.srcL);
+ vex_printf(", ");
+ ppHRegARM(i->ARMin.VMinMaxNum.srcR);
+ return;
+ }
case ARMin_FPSCR:
if (i->ARMin.FPSCR.toFPSCR) {
vex_printf("fmxr fpscr, ");
@@ -2289,6 +2312,11 @@
addHRegUse(u, HRmWrite, i->ARMin.VRIntR.dst);
addHRegUse(u, HRmRead, i->ARMin.VRIntR.src);
return;
+ case ARMin_VMinMaxNum:
+ addHRegUse(u, HRmWrite, i->ARMin.VMinMaxNum.dst);
+ addHRegUse(u, HRmRead, i->ARMin.VMinMaxNum.srcL);
+ addHRegUse(u, HRmRead, i->ARMin.VMinMaxNum.srcR);
+ return;
case ARMin_FPSCR:
if (i->ARMin.FPSCR.toFPSCR)
addHRegUse(u, HRmRead, i->ARMin.FPSCR.iReg);
@@ -2508,6 +2536,14 @@
i->ARMin.VRIntR.dst = lookupHRegRemap(m, i->ARMin.VRIntR.dst);
i->ARMin.VRIntR.src = lookupHRegRemap(m, i->ARMin.VRIntR.src);
return;
+ case ARMin_VMinMaxNum:
+ i->ARMin.VMinMaxNum.dst
+ = lookupHRegRemap(m, i->ARMin.VMinMaxNum.dst);
+ i->ARMin.VMinMaxNum.srcL
+ = lookupHRegRemap(m, i->ARMin.VMinMaxNum.srcL);
+ i->ARMin.VMinMaxNum.srcR
+ = lookupHRegRemap(m, i->ARMin.VMinMaxNum.srcR);
+ return;
case ARMin_FPSCR:
i->ARMin.FPSCR.iReg = lookupHRegRemap(m, i->ARMin.FPSCR.iReg);
return;
@@ -3900,6 +3936,38 @@
isF64 ? X1011 : X1010, X0100 | (M << 1), Vm);
goto done;
}
+ case ARMin_VMinMaxNum: {
+ Bool isF64 = i->ARMin.VMinMaxNum.isF64;
+ Bool isMax = i->ARMin.VMinMaxNum.isMax;
+ UInt rDst = (isF64 ? dregEnc : fregEnc)(i->ARMin.VMinMaxNum.dst);
+ UInt rSrcL = (isF64 ? dregEnc : fregEnc)(i->ARMin.VMinMaxNum.srcL);
+ UInt rSrcR = (isF64 ? dregEnc : fregEnc)(i->ARMin.VMinMaxNum.srcR);
+ /* The encoding of registers here differs strangely for the
+ F32 and F64 cases. */
+ UInt D, Vd, N, Vn, M, Vm;
+ if (isF64) {
+ D = (rDst >> 4) & 1;
+ Vd = rDst & 0xF;
+ N = (rSrcL >> 4) & 1;
+ Vn = rSrcL & 0xF;
+ M = (rSrcR >> 4) & 1;
+ Vm = rSrcR & 0xF;
+ } else {
+ Vd = (rDst >> 1) & 0xF;
+ D = rDst & 1;
+ Vn = (rSrcL >> 1) & 0xF;
+ N = rSrcL & 1;
+ Vm = (rSrcR >> 1) & 0xF;
+ M = rSrcR & 1;
+ }
+ vassert(D <= 1 && Vd <= 15 && M <= 1 && Vm <= 15 && N <= 1
+ && Vn <= 15);
+ *p++ = XXXXXXXX(X1111,X1110, X1000 | (D << 2), Vn, Vd,
+ X1010 | (isF64 ? 1 : 0),
+ (N << 3) | ((isMax ? 0 : 1) << 2) | (M << 1) | 0,
+ Vm);
+ goto done;
+ }
case ARMin_FPSCR: {
Bool toFPSCR = i->ARMin.FPSCR.toFPSCR;
UInt iReg = iregEnc(i->ARMin.FPSCR.iReg);
Modified: trunk/priv/host_arm_defs.h
==============================================================================
--- trunk/priv/host_arm_defs.h (original)
+++ trunk/priv/host_arm_defs.h Fri Jan 13 17:58:57 2017
@@ -596,6 +596,7 @@
ARMin_VXferS,
ARMin_VCvtID,
ARMin_VRIntR,
+ ARMin_VMinMaxNum,
ARMin_FPSCR,
ARMin_MFence,
ARMin_CLREX,
@@ -861,6 +862,15 @@
HReg dst;
HReg src;
} VRIntR;
+ /* Do Min/Max of F32 or F64 values, propagating the numerical arg
+ if the other is a qNaN. For ARM >= V8 hosts only. */
+ struct {
+ Bool isF64;
+ Bool isMax;
+ HReg dst;
+ HReg srcL;
+ HReg srcR;
+ } VMinMaxNum;
/* Move a 32-bit value to/from the FPSCR (FMXR, FMRX) */
struct {
Bool toFPSCR;
@@ -1016,6 +1026,8 @@
extern ARMInstr* ARMInstr_VCvtID ( Bool iToD, Bool syned,
HReg dst, HReg src );
extern ARMInstr* ARMInstr_VRIntR ( Bool isF64, HReg dst, HReg src );
+extern ARMInstr* ARMInstr_VMinMaxNum ( Bool isF64, Bool isMax,
+ HReg dst, HReg srcL, HReg srcR );
extern ARMInstr* ARMInstr_FPSCR ( Bool toFPSCR, HReg iReg );
extern ARMInstr* ARMInstr_MFence ( void );
extern ARMInstr* ARMInstr_CLREX ( void );
Modified: trunk/priv/host_arm_isel.c
==============================================================================
--- trunk/priv/host_arm_isel.c (original)
+++ trunk/priv/host_arm_isel.c Fri Jan 13 17:58:57 2017
@@ -5618,6 +5618,21 @@
/* not a V8 target, so we can't select insns for this. */
break;
}
+ case Iop_MaxNumF64:
+ case Iop_MinNumF64: {
+ /* Same comments regarding V8 support as for Iop_RoundF64toInt. */
+ if (VEX_ARM_ARCHLEVEL(env->hwcaps) >= 8) {
+ HReg srcL = iselDblExpr(env, e->Iex.Binop.arg1);
+ HReg srcR = iselDblExpr(env, e->Iex.Binop.arg2);
+ HReg dst = newVRegD(env);
+ Bool isMax = e->Iex.Binop.op == Iop_MaxNumF64;
+ addInstr(env, ARMInstr_VMinMaxNum(
+ True/*isF64*/, isMax, dst, srcL, srcR));
+ return dst;
+ }
+ /* not a V8 target, so we can't select insns for this. */
+ break;
+ }
default:
break;
}
@@ -5775,6 +5790,21 @@
/* not a V8 target, so we can't select insns for this. */
break;
}
+ case Iop_MaxNumF32:
+ case Iop_MinNumF32: {
+ /* Same comments regarding V8 support as for Iop_RoundF32toInt. */
+ if (VEX_ARM_ARCHLEVEL(env->hwcaps) >= 8) {
+ HReg srcL = iselFltExpr(env, e->Iex.Binop.arg1);
+ HReg srcR = iselFltExpr(env, e->Iex.Binop.arg2);
+ HReg dst = newVRegF(env);
+ Bool isMax = e->Iex.Binop.op == Iop_MaxNumF32;
+ addInstr(env, ARMInstr_VMinMaxNum(
+ False/*!isF64*/, isMax, dst, srcL, srcR));
+ return dst;
+ }
+ /* not a V8 target, so we can't select insns for this. */
+ break;
+ }
default:
break;
}
Modified: trunk/priv/ir_defs.c
==============================================================================
--- trunk/priv/ir_defs.c (original)
+++ trunk/priv/ir_defs.c Fri Jan 13 17:58:57 2017
@@ -354,6 +354,11 @@
case Iop_RecpExpF64: vex_printf("RecpExpF64"); return;
case Iop_RecpExpF32: vex_printf("RecpExpF32"); return;
+ case Iop_MaxNumF64: vex_printf("MaxNumF64"); return;
+ case Iop_MinNumF64: vex_printf("MinNumF64"); return;
+ case Iop_MaxNumF32: vex_printf("MaxNumF32"); return;
+ case Iop_MinNumF32: vex_printf("MinNumF32"); return;
+
case Iop_F16toF64: vex_printf("F16toF64"); return;
case Iop_F64toF16: vex_printf("F64toF16"); return;
case Iop_F16toF32: vex_printf("F16toF32"); return;
@@ -2838,7 +2843,13 @@
case Iop_RecpExpF32:
BINARY(ity_RMode,Ity_F32, Ity_F32);
- case Iop_CmpF32:
+ case Iop_MaxNumF64: case Iop_MinNumF64:
+ BINARY(Ity_F64,Ity_F64, Ity_F64);
+
+ case Iop_MaxNumF32: case Iop_MinNumF32:
+ BINARY(Ity_F32,Ity_F32, Ity_F32);
+
+ case Iop_CmpF32:
BINARY(Ity_F32,Ity_F32, Ity_I32);
case Iop_CmpF64:
Modified: trunk/pub/libvex_ir.h
==============================================================================
--- trunk/pub/libvex_ir.h (original)
+++ trunk/pub/libvex_ir.h Fri Jan 13 17:58:57 2017
@@ -776,6 +776,13 @@
Iop_RecpExpF64, /* FRECPX d :: IRRoundingMode(I32) x F64 -> F64 */
Iop_RecpExpF32, /* FRECPX s :: IRRoundingMode(I32) x F32 -> F32 */
+ /* --------- Possibly required by IEEE 754-2008. --------- */
+
+ Iop_MaxNumF64, /* max, F64, numerical operand if other is a qNaN */
+ Iop_MinNumF64, /* min, F64, ditto */
+ Iop_MaxNumF32, /* max, F32, ditto */
+ Iop_MinNumF32, /* min, F32, ditto */
+
/* ------------------ 16-bit scalar FP ------------------ */
Iop_F16toF64, /* F16 -> F64 */
|
|
From: <sv...@va...> - 2017-01-13 16:29:21
|
Author: petarj
Date: Fri Jan 13 16:29:15 2017
New Revision: 16201
Log:
mips64: update exp file for test_math
Leave the old exp file that covers cases in which __addtf3 and __subtf3
did not take into account rounding modes. New exp file is the same file
that already exists in mips32 folder, so we just create a symbolic link
to it.
Added:
trunk/none/tests/mips64/test_math.stdout.exp (with props)
trunk/none/tests/mips64/test_math.stdout.exp-older-gcc
- copied unchanged from r16200, trunk/none/tests/mips64/test_math.stdout.exp
Modified:
trunk/none/tests/mips64/Makefile.am
Modified: trunk/none/tests/mips64/Makefile.am
==============================================================================
--- trunk/none/tests/mips64/Makefile.am (original)
+++ trunk/none/tests/mips64/Makefile.am Fri Jan 13 16:29:15 2017
@@ -55,7 +55,8 @@
test_block_size.vgtest \
test_fcsr.stdout.exp test_fcsr.stderr.exp \
test_fcsr.vgtest \
- test_math.stdout.exp test_math.stderr.exp test_math.vgtest \
+ test_math.stdout.exp test_math.stdout.exp-older-gcc \
+ test_math.stderr.exp test_math.vgtest \
unaligned_load.stdout.exp-BE unaligned_load.stdout.exp-LE \
unaligned_load.stderr.exp unaligned_load.vgtest \
unaligned_load_store.stdout.exp-LE unaligned_load_store.stdout.exp-BE \
Added: trunk/none/tests/mips64/test_math.stdout.exp
==============================================================================
--- trunk/none/tests/mips64/test_math.stdout.exp (added)
+++ trunk/none/tests/mips64/test_math.stdout.exp Fri Jan 13 16:29:15 2017
@@ -0,0 +1 @@
+link ../mips32/test_math.stdout.exp
\ No newline at end of file
|
|
From: <sv...@va...> - 2017-01-13 12:51:37
|
Author: sewardj
Date: Fri Jan 13 12:51:29 2017
New Revision: 3292
Log:
Implement:
VRINT{Z,R}.F64.F64 d_d, VRINT{Z,R}.F32.F32 s_s
VCVT{A,N,P,M}{.S32,.U32}{.F64,.F32}
Modified:
trunk/priv/guest_arm_toIR.c
Modified: trunk/priv/guest_arm_toIR.c
==============================================================================
--- trunk/priv/guest_arm_toIR.c (original)
+++ trunk/priv/guest_arm_toIR.c Fri Jan 13 12:51:29 2017
@@ -13508,7 +13508,6 @@
nCC(cond), isF64 ? "f64" : "f32", rch, dd, rch, nn, rch, mm);
return True;
}
- /* fall through */
/* -------- VRINT{A,N,P,M}.F64 d_d, VRINT{A,N,P,M}.F32 s_s -------- */
/* 31 22 21 17 15 11 8 7 5 4 3
@@ -13557,11 +13556,114 @@
(isF64 ? llPutDReg : llPutFReg)(dd, res);
UChar rch = isF64 ? 'd' : 'f';
- DIP("vrint%c.%s %c%u, %c%u\n",
- c, isF64 ? "f64" : "f32", rch, dd, rch, mm);
+ DIP("vrint%c.%s.%s %c%u, %c%u\n",
+ c, isF64 ? "f64" : "f32", isF64 ? "f64" : "f32", rch, dd, rch, mm);
+ return True;
+ }
+
+ /* -------- VRINT{Z,R}.F64.F64 d_d, VRINT{Z,R}.F32.F32 s_s -------- */
+ /* 31 27 22 21 15 11 7 6 5 4 3
+ T1: 1110 11101 D 110110 Vd 1011 op 1 M 0 Vm VRINT<r><c>.F64.F64 Dd, Dm
+ A1: cond 11101 D 110110 Vd 1011 op 1 M 0 Vm
+
+ T1: 1110 11101 D 110110 Vd 1010 op 1 M 0 Vm VRINT<r><c>.F32.F32 Sd, Sm
+ A1: cond 11101 D 110110 Vd 1010 op 1 M 0 Vm
+
+ In contrast to the VRINT variants just above, this can be conditional.
+ */
+ if ((isT ? (INSN(31,28) == BITS4(1,1,1,0)) : True)
+ && INSN(27,23) == BITS5(1,1,1,0,1) && INSN(21,16) == BITS6(1,1,0,1,1,0)
+ && INSN(11,9) == BITS3(1,0,1) && INSN(6,6) == 1 && INSN(4,4) == 0) {
+ UInt bit_D = INSN(22,22);
+ UInt fld_Vd = INSN(15,12);
+ Bool isF64 = INSN(8,8) == 1;
+ Bool rToZero = INSN(7,7) == 1;
+ UInt bit_M = INSN(5,5);
+ UInt fld_Vm = INSN(3,0);
+ UInt dd = isF64 ? ((bit_D << 4) | fld_Vd) : ((fld_Vd << 1) | bit_D);
+ UInt mm = isF64 ? ((bit_M << 4) | fld_Vm) : ((fld_Vm << 1) | bit_M);
+
+ if (isT) vassert(condT != IRTemp_INVALID);
+ IRType ty = isF64 ? Ity_F64 : Ity_F32;
+ IRTemp src = newTemp(ty);
+ IRTemp res = newTemp(ty);
+ assign(src, (isF64 ? getDReg : getFReg)(mm));
+
+ IRTemp rm = newTemp(Ity_I32);
+ assign(rm, rToZero ? mkU32(Irrm_ZERO)
+ : mkexpr(mk_get_IR_rounding_mode()));
+ assign(res, binop(isF64 ? Iop_RoundF64toInt : Iop_RoundF32toInt,
+ mkexpr(rm), mkexpr(src)));
+ (isF64 ? putDReg : putFReg)(dd, mkexpr(res), condT);
+
+ UChar rch = isF64 ? 'd' : 'f';
+ DIP("vrint%c.%s.%s %c%u, %c%u\n",
+ rToZero ? 'z' : 'r',
+ isF64 ? "f64" : "f32", isF64 ? "f64" : "f32", rch, dd, rch, mm);
+ return True;
+ }
+
+ /* ----------- VCVT{A,N,P,M}{.S32,.U32}{.F64,.F32} ----------- */
+ /* 31 27 22 21 17 15 11 8 7 6 5 4 3
+ T1/A1: 1111 11101 D 1111 rm Vd 101 sz op 1 M 0 Vm
+ VCVT{A,N,P,M}{.S32,.U32}.F64 Sd, Dm
+ VCVT{A,N,P,M}{.S32,.U32}.F32 Sd, Sm
+
+ ARM encoding is in NV space.
+ In Thumb mode, we must not be in an IT block.
+ */
+ if (INSN(31,23) == BITS9(1,1,1,1,1,1,1,0,1) && INSN(21,18) == BITS4(1,1,1,1)
+ && INSN(11,9) == BITS3(1,0,1) && INSN(6,6) == 1 && INSN(4,4) == 0) {
+ UInt bit_D = INSN(22,22);
+ UInt fld_rm = INSN(17,16);
+ UInt fld_Vd = INSN(15,12);
+ Bool isF64 = INSN(8,8) == 1;
+ Bool isU = INSN(7,7) == 0;
+ UInt bit_M = INSN(5,5);
+ UInt fld_Vm = INSN(3,0);
+
+ UInt dd = (fld_Vd << 1) | bit_D;
+ UInt mm = isF64 ? ((bit_M << 4) | fld_Vm) : ((fld_Vm << 1) | bit_M);
+
+ if (isT) {
+ gen_SIGILL_T_if_in_ITBlock(old_itstate, new_itstate);
+ }
+ /* In ARM mode, this is statically unconditional. In Thumb mode,
+ this must be dynamically unconditional, and we've SIGILLd if not.
+ In either case we can create unconditional IR. */
+
+ UChar c = '?';
+ IRRoundingMode rm = Irrm_NEAREST;
+ switch (fld_rm) {
+ /* The use of NEAREST for both the 'a' and 'n' cases is a bit of a
+ kludge since it doesn't take into account the nearest-even vs
+ nearest-away semantics. */
+ case BITS2(0,0): c = 'a'; rm = Irrm_NEAREST; break;
+ case BITS2(0,1): c = 'n'; rm = Irrm_NEAREST; break;
+ case BITS2(1,0): c = 'p'; rm = Irrm_PosINF; break;
+ case BITS2(1,1): c = 'm'; rm = Irrm_NegINF; break;
+ default: vassert(0);
+ }
+
+ IRExpr* srcM = (isF64 ? llGetDReg : llGetFReg)(mm);
+ IRTemp res = newTemp(Ity_I32);
+
+ /* The arm back end doesn't support use of Iop_F32toI32U or
+ Iop_F32toI32S, so for those cases we widen the F32 to F64
+ and then follow the F64 route. */
+ if (!isF64) {
+ srcM = unop(Iop_F32toF64, srcM);
+ }
+ assign(res, binop(isU ? Iop_F64toI32U : Iop_F64toI32S,
+ mkU32((UInt)rm), srcM));
+
+ llPutFReg(dd, unop(Iop_ReinterpI32asF32, mkexpr(res)));
+
+ UChar rch = isF64 ? 'd' : 'f';
+ DIP("vcvt%c.%s.%s %c%u, %c%u\n",
+ c, isU ? "u32" : "s32", isF64 ? "f64" : "f32", 's', dd, rch, mm);
return True;
}
- /* fall through */
/* ---------- Doesn't match anything. ---------- */
return False;
|
|
From: Ivo R. <iv...@iv...> - 2017-01-13 10:41:35
|
2017-01-12 20:36 GMT+01:00 Philippe Waroquiers < phi...@sk...>: > On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote: > > On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...> > wrote: > > > On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers > > > <phi...@sk...> wrote: > > >> No sign of any tilegx user or developer activity since something like > > >> one year. > > >> No reply received for question in > > >> https://sourceforge.net/p/valgrind/mailman/message/35566192/ > > >> > > >> Is there any tilegx user or developer still active ? > > >> Should we consider this platform as dead ? > > >> > > > I have exchanged a few emails with Tilera/Mellanox compiler enigneers, > > > and they say they cannot take care of TileGx port in Valgrind for the > > > time being. > > > > Is there any emulator or other way we can use to test changes ? I > > don't like seeing such a port just disappear... > Well, if there is > no known users, > and no (original) developer doing maintenance > and no reply from (original) developers to simple questions > and no access to a system to test/compile > and no nightly build > and no tests in SVN > and no emulator > then IMO, this platform is a candidate to remove. > as just keeping this compiling forever for no reason will > at the end cost more than just removing it. > Agreed here. Although there are regtests under none/tests/tilegx there is no way to run them without any access to the machine or emulator. I. |