Dear all,

I've come across a strange behavior with GCC 4.7.1 (compiling to an SSE2-capable processor) when trying to access the high and low 64-bit words of a 128-bit SSE register, as in the following testcase:

----8<----
#include <stdint.h>
#include <emmintrin.h>

int test(const __m128i x)
{
  union { __m128i v; uint64_t ui[2]; } c;
  c.v = x;
  return !(c.ui[0] | c.ui[1]);
}
---->8----

When compiling with -O2 or -O3, I obtain the following assembly code:

----8<----
test:
.LFB519:
        .cfi_startproc
        movdqa  %xmm0, -40(%rsp)
        movq    -40(%rsp), %rax
        movdqa  %xmm0, -24(%rsp)
        movq    %rax, %rdx
        orq     -16(%rsp), %rdx
        sete    %al
        movzbl  %al, %eax
        ret
        .cfi_endproc
---->8----

Note the two movdqa instructions storing %xmm0 to the stack: the first one to -40(%rsp), followed by an access the low 64 bits of %xmm0 at the same address, and the second one to -24(%rsp), followed by an access the high 64 bits at -16(%rsp). Obviously, one of the two movdqa's is useless.

Also note that replacing the union-based type-punning by a memcpy produces the same assembly code.

This behavior was also reproduced with GCC 4.4.7, 4.5.3, and 4.6.3. However, it does not happen with GCC 4.1.2. I haven't been able to narrow it down any further.

A short investigation (given my very limited understanding of the internals of GCC) suggests that the problem originates from the first Dead-Store Elimination (dse1) pass. After the cse2 pass, the RTL looks correct:

----8<----
[...]
(insn 6 3 7 2 (set (mem/c:V2DI (plus:DI (reg/f:DI 20 frame)
                (const_int -16 [0xfffffffffffffff0])) [0 c.v+0 S16 A128])
        (reg/v:V2DI 65 [ x ])) test.c:7 1096 {*movv2di_internal}
     (expr_list:REG_DEAD (reg/v:V2DI 65 [ x ])
        (nil)))

(insn 7 6 8 2 (set (reg:DI 67 [ c.ui ])
        (mem/c:DI (plus:DI (reg/f:DI 20 frame)
                (const_int -16 [0xfffffffffffffff0])) [0 c.ui+0 S8 A128])) test.c:8 62 {*movdi_internal_rex64}
     (nil))

(insn 8 7 9 2 (set (reg:DI 68 [ c.ui+8 ])
        (mem/c:DI (plus:DI (reg/f:DI 20 frame)
                (const_int -8 [0xfffffffffffffff8])) [0 c.ui+8 S8 A64])) test.c:8 62 {*movdi_internal_rex64}
     (nil))
[...]
---->8----

Here, if I'm not mistaken, the V2DImode register containing x is stored at -16(%frame_ptr), and its low and high 64-bit parts are accessed at -16(%frame_ptr) and -8(%frame_ptr), respectively.

However, this changes after the next pass (dse1):

----8<----
[...]
(insn 24 3 25 2 (set (reg:DI 72)
        (subreg:DI (reg/v:V2DI 65 [ x ]) 0)) test.c:7 -1
     (nil))

(insn 25 24 6 2 (set (reg:DI 73)
        (reg:DI 72)) test.c:7 -1
     (expr_list:REG_DEAD (reg:DI 72)
        (nil)))

(insn 6 25 7 2 (set (mem/c:V2DI (plus:DI (reg/f:DI 20 frame)
                (const_int -16 [0xfffffffffffffff0])) [0 c.v+0 S16 A128])
        (reg/v:V2DI 65 [ x ])) test.c:7 1096 {*movv2di_internal}
     (expr_list:REG_DEAD (reg/v:V2DI 65 [ x ])
        (nil)))

(insn 7 6 8 2 (set (reg:DI 67 [ c.ui ])
        (reg:DI 73)) test.c:8 62 {*movdi_internal_rex64}
     (expr_list:REG_DEAD (reg:DI 73)
        (nil)))

(insn 8 7 9 2 (set (reg:DI 68 [ c.ui+8 ])
        (mem/c:DI (plus:DI (reg/f:DI 20 frame)
                (const_int -8 [0xfffffffffffffff8])) [0 c.ui+8 S8 A64])) test.c:8 62 {*movdi_internal_rex64}
     (nil))
[...]
---->8----

Here, two extra instructions (24 and 25) were added to access the low part of x directly, without bothering to store it in memory first. This is confirmed by the dse1 dump, which reads as follows:

----8<----
[...]
**scanning insn=7
  mem: (plus:DI (reg/f:DI 20 frame)
    (const_int -16 [0xfffffffffffffff0]))

   after canon_rtx address: (plus:DI (reg/f:DI 20 frame)
    (const_int -16 [0xfffffffffffffff0]))
  gid=0 offset=-16 
 processing const load gid=0[-16..-8)
trying to replace DImode load in insn 7 from V2DImode store in insn 6
deferring rescan insn with uid = 7.
deferring rescan insn with uid = 24.
deferring rescan insn with uid = 25.
 -- replaced the loaded MEM with (reg 73)
mems_found = 0, cannot_delete = true
[...]
---->8----

Then, in pass subreg2, GCC decides to split the V2DImode register into two DImode subregs. This generates a truckload of extra instructions, whose operands eventually get spilled to memory in the reload pass. This is where I think the extra movqda is coming from.

Thanks a lot for your help!
Cheers,
Jérémie.