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: unassig...@gcc.gnu.org
ReportedBy: jeremie.det...@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.
