[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-07 Thread hjl at gcc dot gnu dot org
--- 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=gccview=revrev=138839 Log: gcc/ 2008-08-07 H.J. Lu [EMAIL PROTECTED] PR target/36992

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-07 Thread hjl dot tools at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-05 Thread hjl dot tools at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-05 Thread hjl dot tools at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-05 Thread hjl at gcc dot gnu dot org
--- 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=gccview=revrev=138734 Log: gcc/ 2008-08-05 H.J. Lu [EMAIL PROTECTED] PR target/36992

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-03 Thread uros at gcc dot gnu dot org
--- 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=gccview=revrev=138564 Log: PR target/36992 * config/i386/sse.md

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-03 Thread ubizjak at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread ubizjak at gmail dot com
--- Comment #9 from ubizjak at gmail dot com 2008-08-02 13:08 --- Hm, IA-32 Intel® Architecture Software Developer’s Manual says about movq: Operation MOVQ instruction when operating on MMX technology registers and memory locations: DEST #8592; SRC; MOVQ instruction when source and

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread ubizjak at gmail dot com
--- Comment #10 from ubizjak at gmail dot com 2008-08-02 13:10 --- #8592; in my previous post represents left pointing arrow, . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread ubizjak at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread ubizjak at gmail dot com
--- 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) +++

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread hjl dot tools at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread ubizjak at gmail dot com
--- 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 === ---

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-02 Thread ubizjak at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread rguenth at gcc dot gnu dot org
--- 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)); }

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread rguenth at gcc dot gnu dot org
--- 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. --

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread hjl dot tools at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread hjl dot tools at gmail dot com
--- 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 %xmm0,

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread hjl dot tools at gmail dot com
--- 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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-01 Thread ubizjak at gmail dot com
--- 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