[PATCH] D41516: emmintrin.h documentation fixes and updates

[Eli Friedman via Phabricator via cfe-commits]

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:
> 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?
Testcase:

```
#include <immintrin.h>
__m128 foo(__m128i a, __m128 c)
{
  return _mm_movpi64_epi64(_mm_add_pi8(_mm_movepi64_pi64(a), _mm_set1_pi8(5)));
}
```

In this case, we should generate movq2dq, but currently don't (I assume due to a missing DAGCombine).  I don't see how you could ever get MOVD... but see https://reviews.llvm.org/rL321898, which could be the source of some confusion.


Repository:
  rL LLVM

https://reviews.llvm.org/D41516