efriedma added inline comments.
================ Comment at: cfe/trunk/lib/Headers/emmintrin.h:4683 /// -/// This intrinsic has no corresponding instruction. +/// This intrinsic corresponds to the <c> MOVDQ2Q </c> instruction. /// ---------------- kromanova wrote: > kromanova wrote: > > I'm not sure about this change. > > > > Intel documentation says they generate MOVDQ2Q (don't have icc handy to > > try). > > However, I've tried on Linux/X86_64 with clang and gcc, - and we just > > return. > > > Though I suspect it's possible to generate movdq2q, I couldn't come up with > an test to trigger this instruction generation. > Should we revert this change? > > > ``` > __m64 fooepi64_pi64 (__m128i a, __m128 c) > { > __m64 x; > > x = _mm_movepi64_pi64 (a); > return x; > } > > ``` > > on Linux we generate return instruction. > I would expect (v)movq %xmm0,%rax to be generated instead of retq. > Am I missing something? Why do we return 64 bit integer in xmm register > rather than in %rax? > The x86-64 calling convention rules say that __m64 is passed/returned in SSE registers. Try the following, which generates movdq2q: ``` __m64 foo(__m128i a, __m128 c) { return _mm_add_pi8(_mm_movepi64_pi64(a), _mm_set1_pi8(5)); } ``` Repository: rL LLVM https://reviews.llvm.org/D41516 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits