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
(6) |
2
(6) |
3
(10) |
4
(10) |
|
5
(6) |
6
(6) |
7
(9) |
8
(6) |
9
(6) |
10
(7) |
11
(7) |
|
12
(6) |
13
(6) |
14
(8) |
15
(17) |
16
(10) |
17
(17) |
18
(8) |
|
19
(9) |
20
(7) |
21
(6) |
22
(6) |
23
(6) |
24
(5) |
25
(3) |
|
26
(3) |
27
(3) |
28
(3) |
29
(3) |
30
(2) |
31
(3) |
|
|
From: Jeremy F. <je...@go...> - 2004-12-15 19:23:45
|
On Wed, 2004-12-15 at 18:31 +0000, Julian Seward wrote: > What one might interpret it to mean is that this is a microarchitectural > hack from Intel. The different variants of each instruction effectively > give a hint about which forwarding path the instruction's results > should be sent along. If you keep the types consistent, data might get > to the next functional unit (or whatever) sooner; if you mix up types, > the results are still the same, but results have to be shunted along > longer, slower forwarding paths. That's what I guessed too. AMD says the same thing about Opteron, though their document goes into a bit more detail. For example, if you use the half-register forms and mix two types within one register, it doesn't matter if you use scalar ops, but it will hurt SIMD vector ops. J |
|
From: Julian S. <js...@ac...> - 2004-12-15 18:31:38
|
On Wednesday 15 December 2004 18:04, Jeremy Fitzhardinge wrote: > The Intel optimisation guide says: > When writing SSE2 code that works with both integer and > floating-point data, use the subset of SIMD convert instructions > or load/store instructions to ensure the input operands in XMM > registers contain properly defined data type to match the > instruction. Code sequences containing cross-typed usage will > produce the same results across different implementations, but > will incur a significant performance penalty. Using SSE or SSE2 > instructions to operate on type-mismatched SIMD data in the XMM > register is strongly discouraged. > > (point 2 of "General Rules on SIMD Integer code", in chapter 4) Jeremy. Thanks for digging that up. What one might interpret it to mean is that this is a microarchitectural hack from Intel. The different variants of each instruction effectively give a hint about which forwarding path the instruction's results should be sent along. If you keep the types consistent, data might get to the next functional unit (or whatever) sooner; if you mix up types, the results are still the same, but results have to be shunted along longer, slower forwarding paths. Any microarchitects out there have a clue about this? J |
|
From: Jeremy F. <je...@go...> - 2004-12-15 18:04:13
|
On Wed, 2004-12-15 at 14:04 +0000, Julian Seward wrote:
> I've been staring a lot at SSE/SSE2 lately. There seem to be
> a number of instructions with different encodings but which
> behave exactly the same:
>
> MOVQ, MOVSD
> ANDPS, ANDPD, PAND
> ORPS, ORPD, POR
> XORPS, XORPD, PXOR
>
> I'm sure there are more, but I didn't record them.
>
> Can anyone cast any light on this? Are they really different in
> some subtle way? If not, why would Intel (a) use up encoding
> space on multiple versions of the same thing, and (b) confuse
> people with meaningless type qualifiers ("PS", "PD") on and/or/xor?
The Intel optimisation guide says:
When writing SSE2 code that works with both integer and
floating-point data, use the subset of SIMD convert instructions
or load/store instructions to ensure the input operands in XMM
registers contain properly defined data type to match the
instruction. Code sequences containing cross-typed usage will
produce the same results across different implementations, but
will incur a significant performance penalty. Using SSE or SSE2
instructions to operate on type-mismatched SIMD data in the XMM
register is strongly discouraged.
(point 2 of "General Rules on SIMD Integer code", in chapter 4)
In other words, bits are not bits - they have type.
J
|
|
From: Bryan O'S. <bo...@se...> - 2004-12-15 17:49:19
|
On Wed, 2004-12-15 at 14:04 +0000, Julian Seward wrote:
> I've been staring a lot at SSE/SSE2 lately. There seem to be
> a number of instructions with different encodings but which
> behave exactly the same:
>
> MOVQ, MOVSD
> ANDPS, ANDPD, PAND
> ORPS, ORPD, POR
> XORPS, XORPD, PXOR
>
> I'm sure there are more, but I didn't record them.
>
> Can anyone cast any light on this? Are they really different in
> some subtle way?
This is more of a historical question than a behavioural one.
The instructions with the P* prefix date back to MMX, which was Intel's
rushed response to Sun's VIS instructions circa 1996.
Most of the *PS instructions operate on packed single-precision (32-bit)
FP quantities, and hail from SSE.
Most of the *PD instructions operate on packed double-precision (64-bit)
FP quantities, and come from SSE2.
Since the instructions you list are all logical operations, I'd be a bit
surprised if they had visibly different effects, but perhaps they set
flags differently based on the contents and sizes of their results.
> If not, why would Intel (a) use up encoding
> space on multiple versions of the same thing, and (b) confuse
> people with meaningless type qualifiers ("PS", "PD") on and/or/xor?
Perhaps the instruction decoder and data paths gave them the encodings
"for free". Or else it could simply be a desire to preserve symmetry,
to make life easier for code generators or something.
<b
|
|
From: Naveen K. <g_n...@ya...> - 2004-12-15 16:15:51
|
Tom you were right. Thanks. Naveen --- Tom Hughes <th...@cy...> wrote: > In message > <200...@we...> > Naveen Kumar <g_n...@ya...> wrote: > > > so vgPlain_open is present but where does > > vgPlain_open64 come from ? > > You have probably included a system header file that > redefines > open as open64. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo |
|
From: Tom H. <th...@cy...> - 2004-12-15 16:08:51
|
In message <200...@we...>
Naveen Kumar <g_n...@ya...> wrote:
> so vgPlain_open is present but where does
> vgPlain_open64 come from ?
You have probably included a system header file that redefines
open as open64.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Naveen K. <g_n...@ya...> - 2004-12-15 15:44:43
|
J, I am slightly consfused. VG_(open) expands to vgPlain_open does it not ? vg_mylibc.c defines a VG_(open)(...) i.e vgPlain_open(...) so the linker shouldn't complain that VG_(open) in vg_main.c is not found. I understand that the implementation on VG_(open) wont work for solaris but shouldn't it be able to atleast link everything. I did an "nm" on vg_mylibc.o for open this is what I get. nm vg_mylibc.o | grep open 00001a74 T vgPlain_open so vgPlain_open is present but where does vgPlain_open64 come from ? Naveen --- Jeremy Fitzhardinge <je...@go...> wrote: > On Tue, 2004-12-14 at 12:42 -0800, Naveen Kumar > wrote: > > Hi folks, > > I have attempting to build valgrind on > Solaris-x86. > > I am having problems during linking. I get the > error > > > > vg_main.o: In function `get_file_clo': > > /home/msat/port/valgrind/coregrind/vg_main.c:524: > > undefined reference to `vgPlain_open64' > > > > There are similar errors for vgPlain_getrlimit64 & > > vgPlain_setrlimit64. > > These are linux syscalls. You're going to need to > work out what the > appropriate syscalls for Solaris are. You're also > going to need to > create a coregrind/x86-solaris, and put *.S files in > there. A > definition of VG_(do_syscall) will be the first > priority. A lot of > vg_mylibc.c is also Linux-specific, so you'll need > to come up with a > Solaris-specific version. > > > > > Also I get these statements(warnings ?) from ld. > > > > /usr/local/bin/ld: section .rodata [00000160 -> > > 0001d17f] overlaps section .text [00000000 -> > > 0005be7f] > > [...] > > Can somebody point me in the right direction ? > > You're going to have to look into how Solaris/x86 > lays out the address > space for a process, and adjust the generation of > coregrind/x86/stage2.lds accordingly. > > J > > __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com |
|
From: Tom H. <th...@cy...> - 2004-12-15 14:55:23
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> I've been staring a lot at SSE/SSE2 lately. There seem to be
> a number of instructions with different encodings but which
> behave exactly the same:
>
> MOVQ, MOVSD
> ANDPS, ANDPD, PAND
> ORPS, ORPD, POR
> XORPS, XORPD, PXOR
>
> I'm sure there are more, but I didn't record them.
I noticed that when I was writing the SSE tests.
> Can anyone cast any light on this? Are they really different in
> some subtle way? If not, why would Intel (a) use up encoding
> space on multiple versions of the same thing, and (b) confuse
> people with meaningless type qualifiers ("PS", "PD") on and/or/xor?
I have no idea. I can't see any difference in the manual - even
the exceptions that can be raised seem to be the same.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-12-15 14:04:41
|
I've been staring a lot at SSE/SSE2 lately. There seem to be
a number of instructions with different encodings but which
behave exactly the same:
MOVQ, MOVSD
ANDPS, ANDPD, PAND
ORPS, ORPD, POR
XORPS, XORPD, PXOR
I'm sure there are more, but I didn't record them.
Can anyone cast any light on this? Are they really different in
some subtle way? If not, why would Intel (a) use up encoding
space on multiple versions of the same thing, and (b) confuse
people with meaningless type qualifiers ("PS", "PD") on and/or/xor?
J
|
|
From: Jeremy F. <je...@go...> - 2004-12-15 08:50:29
|
On Tue, 2004-12-14 at 12:42 -0800, Naveen Kumar wrote: > Hi folks, > I have attempting to build valgrind on Solaris-x86. > I am having problems during linking. I get the error > > vg_main.o: In function `get_file_clo': > /home/msat/port/valgrind/coregrind/vg_main.c:524: > undefined reference to `vgPlain_open64' > > There are similar errors for vgPlain_getrlimit64 & > vgPlain_setrlimit64. These are linux syscalls. You're going to need to work out what the appropriate syscalls for Solaris are. You're also going to need to create a coregrind/x86-solaris, and put *.S files in there. A definition of VG_(do_syscall) will be the first priority. A lot of vg_mylibc.c is also Linux-specific, so you'll need to come up with a Solaris-specific version. > > Also I get these statements(warnings ?) from ld. > > /usr/local/bin/ld: section .rodata [00000160 -> > 0001d17f] overlaps section .text [00000000 -> > 0005be7f] > [...] > Can somebody point me in the right direction ? You're going to have to look into how Solaris/x86 lays out the address space for a process, and adjust the generation of coregrind/x86/stage2.lds accordingly. J |
|
From: <js...@ac...> - 2004-12-15 03:50:17
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-12-15 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow Nightly build on phoenix ( SuSE 9.1 ) started at 2004-12-15 03:50:00 GMT |
|
From: Tom H. <to...@co...> - 2004-12-15 03:25:46
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2004-12-15 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 12 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-15 03:20:17
|
Nightly build on audi ( Red Hat 9 ) started at 2004-12-15 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-15 03:13:54
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-12-15 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-15 03:08:34
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-12-15 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-15 03:04:05
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-12-15 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2004-12-15 02:25:10
|
On Tue, 2004-12-14 at 23:37 +0000, Nicholas Nethercote wrote: > On Tue, 14 Dec 2004, Naveen Kumar wrote: > > > I have attempting to build valgrind on Solaris-x86. > > Valgrind doesn't work on x86/Solaris, only x86/linux at the moment. > Did it not fail on your x86/Solaris machine at configure time? He's taking the advice it gave him literally, and doing a port. J |