http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894
Bug #: 55894
Summary: No constant propagation in Intel intrinsics
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
I was comparing ways to generate a constant (Intel 12.0 doesn't support the
first one), and noticed that these functions result in different asm. In
particular, there doesn't seem to be a lot of constant propagation going on :-(
-Ofast and various -march only managed to change 'g' to movddup .LC1(%rip),
%xmm0 (which in itself looks better than movapd, except that if I change g to
take an argument __m128d a and return _mm_xor_pd(a,m), that prevents gcc from
compacting it to a single insn, and I really don't see a reason for f and g to
generate different code as they look so similar). By the way, if you have a
suggestion on the simplest portable way to get this constant...
#include <x86intrin.h>
__m128d f(){
const __m128d m = _mm_castsi128_pd (_mm_set1_epi64x (0x7fffffffffffffff));
return m;
}
__m128d g(){
const __m128d m = _mm_castsi128_pd (_mm_set1_epi64
(_mm_set_pi32(0x7fffffff,0xffffffff)));
return m;
}
__m128d h(){
const __m128d x = _mm_set1_pd (-0.);
const __m128d m1 = _mm_cmpeq_pd (x, x);
const __m128d m = _mm_xor_pd (x, m1);
return m;
}
_Z1fv:
.LFB539:
.cfi_startproc
movapd .LC0(%rip), %xmm0
ret
.cfi_endproc
[...]
_Z1gv:
.LFB540:
.cfi_startproc
movq .LC1(%rip), %xmm0
punpcklqdq %xmm0, %xmm0
ret
.cfi_endproc
[...]
_Z1hv:
.LFB541:
.cfi_startproc
movapd .LC3(%rip), %xmm0
movapd %xmm0, %xmm1
cmpeqpd %xmm0, %xmm1
xorpd %xmm1, %xmm0
ret
.cfi_endproc
[...]
.LC0:
.long 4294967295
.long 2147483647
.long 4294967295
.long 2147483647
.section .rodata.cst8,"aM",@progbits,8
.align 8
.LC1:
.long -1
.long 2147483647
.section .rodata.cst16
.align 16
.LC3:
.long 0
.long -2147483648
.long 0
.long -2147483648
