[Bug target/54421] New: Extra movdqa when accessing quadwords in a 128-bit SSE register

[Bug target/54421] New: Extra movdqa when accessing quadwords in a 128-bit SSE register

[Jeremie.Detrey at loria dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54421

             Bug #: 54421
           Summary: Extra movdqa when accessing quadwords in a 128-bit SSE
                    register
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Jeremie.Detrey@loria.fr


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.

[Bug rtl-optimization/54421] Extra movdqa when accessing quadwords in a 128-bit SSE register

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54421

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-03
          Component|target                      |rtl-optimization
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-03 10:34:31 UTC ---
Confirmed.