kromanova 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.
///
----------------
efriedma wrote:
> 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));
> }
> ```
Thanks! That explains it :)
I can see that MOVDQ2Q gets generated.
What about intrinsic below, _mm_movpi64_epi64? Can we ever generate MOVD+VMOVQ
as stated in the review?
Or should we write VMOVQ / MOVQ?
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
