--- Comment #22 from hjl dot tools at gmail dot com 2008-08-07 13:18
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENE
--- Comment #21 from hjl at gcc dot gnu dot org 2008-08-07 13:17 ---
Subject: Bug 36992
Author: hjl
Date: Thu Aug 7 13:16:23 2008
New Revision: 138839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138839
Log:
gcc/
2008-08-07 H.J. Lu <[EMAIL PROTECTED]>
PR target/36
--- Comment #20 from hjl at gcc dot gnu dot org 2008-08-05 17:41 ---
Subject: Bug 36992
Author: hjl
Date: Tue Aug 5 17:40:16 2008
New Revision: 138734
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138734
Log:
gcc/
2008-08-05 H.J. Lu <[EMAIL PROTECTED]>
PR target/36
--- Comment #19 from hjl dot tools at gmail dot com 2008-08-05 17:34
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00324.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #18 from hjl dot tools at gmail dot com 2008-08-05 14:19
---
With -msse4, we got
bash-3.2$ ./xgcc -B./ -msse4 -S
/export/gnu/src/gcc-work/gcc/gcc/testsuite/gcc.target/i386/pr36992-1.c
bash-3.2$ ./xgcc -B./ -msse4 -S
/export/gnu/src/gcc-work/gcc/gcc/testsuite/gcc.target/i386
--- Comment #17 from ubizjak at gmail dot com 2008-08-03 06:49 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from uros at gcc dot gnu dot org 2008-08-03 06:14 ---
Subject: Bug 36992
Author: uros
Date: Sun Aug 3 06:13:04 2008
New Revision: 138564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138564
Log:
PR target/36992
* config/i386/sse.md (vec_concatv2
--- Comment #15 from ubizjak at gmail dot com 2008-08-02 18:43 ---
Complete patch at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00116.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #14 from ubizjak at gmail dot com 2008-08-02 16:01 ---
(In reply to comment #13)
> We should also test -O0.
Usage of MMX regs with -O0 is fixed by following patch:
Index: config/i386/mmx.md
===
--- config/i386/
--- Comment #13 from hjl dot tools at gmail dot com 2008-08-02 15:19
---
We should also test -O0. This code:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_movpi64_epi64 (__m64 __A)
{
return _mm_set_epi64 ((__m64)0LL, __A);
}
extern _
--- Comment #12 from ubizjak at gmail dot com 2008-08-02 15:07 ---
Patch in testing:
Index: testsuite/gcc.target/i386/pr36992.c
===
--- testsuite/gcc.target/i386/pr36992.c (revision 0)
+++ testsuite/gcc.target/i386/pr36992.
--- Comment #11 from ubizjak at gmail dot com 2008-08-02 13:22 ---
Uh, clearing of top bits is explicitly stated in latest Software Developer's
Manual for both movq and movd. I'll fix these patterns.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #10 from ubizjak at gmail dot com 2008-08-02 13:10 ---
"←" in my previous post represents left pointing arrow, <.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
--- Comment #9 from ubizjak at gmail dot com 2008-08-02 13:08 ---
Hm, IA-32 Intel® Architecture Software Developers Manual says about movq:
Operation
MOVQ instruction when operating on MMX technology registers and memory
locations:
DEST ← SRC;
MOVQ instruction when source and destin
--- Comment #8 from ubizjak at gmail dot com 2008-08-01 19:32 ---
(In reply to comment #7)
> But it isn't necessary at all. We should use
>
> movq %xmm0,%xmm0
It looks to me that we should add:
[(set (match_operand:V2DI 0 "register_operand" "=x")
(vec_concat:V2DI
--- Comment #7 from hjl dot tools at gmail dot com 2008-08-01 13:25 ---
(In reply to comment #6)
> with -march=core2 it uses
>
> movd%xmm0, %rax
> movq%rax, %xmm0
>
Even this isn't necessary. We should just use
movq %xmm0,%xmm0
> with -march=opteron (and -marc
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-08-01 13:21 ---
with -march=core2 it uses
movd%xmm0, %rax
movq%rax, %xmm0
with -march=opteron (and -march=generic) it uses
movhps .LC0(%rip), %xmm0
ISTR there is some penalty for using movq on op
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-01 12:55 ---
(In reply to comment #3)
> Btw, 4.3 generates
>
> test:
> .LFB518:
> movhps .LC0(%rip), %xmm0
> ret
>
> Likewise does gcc-4.4 (SUSE Linux) 4.4.0 20080611. And current trunk.
It should be
movq %x
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-01 12:53 ---
(In reply to comment #2)
> Google leads me to VC++ reference which says "Moves the lower 64 bits of the
> lower 64 bits of the result, zeroing the upper bits.
>
> I guess inlining and type fixing messes this up very
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 12:06 ---
Btw, 4.3 generates
test:
.LFB518:
movhps .LC0(%rip), %xmm0
ret
Likewise does gcc-4.4 (SUSE Linux) 4.4.0 20080611. And current trunk.
So ... why are you exactly complaining about the code generate
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-01 12:04 ---
Google leads me to VC++ reference which says "Moves the lower 64 bits of the
lower 64 bits of the result, zeroing the upper bits.
I guess inlining and type fixing messes this up very early.
--
http://gcc.gnu.or
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-01 11:58 ---
It's very (un-)useful that
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_move_epi64 (__m128i __A)
{
return _mm_set_epi64 ((__m64)0LL, _mm_movepi64_pi64 (__A));
}
i
22 matches
Mail list logo
