Any preference to SHUFPD or PSHUFD for reversing two packed double in an XMM?
<p>Question today is fairly short. Consider the following toy C program <code>shuffle.c</code> for reversing two packed double in register <code>xmm0</code>:</p>

<pre><code>#include &lt;stdio.h&gt;

void main () {
  double x[2] = {0.0, 1.0};
  asm volatile (
    "movupd  (%[x]), %%xmm0\n\t"
    "shufpd  $1, %%xmm0, %%xmm0\n\t"  /* method 1 */
    //"pshufd  $78, %%xmm0, %%xmm0\n\t"  /* method 2 */
    "movupd  %%xmm0, (%[x])\n\t"
    :
    : [x] "r" (x)
    : "xmm0", "memory");
  printf("x[0] = %.2f, x[1] = %.2f\n", x[0], x[1]);
  }
</code></pre>

<p>After a dry run: <code>gcc -msse3 -o shuffle shuffle.c | ./test</code>, both methods/instructions will return the correct result <code>x[0] = 1.00, x[1] = 0.00</code>. <a href="http://x86.renejeschke.de/html/file_module_x86_id_293.html" rel="nofollow">This page</a> says that <code>shufpd</code> has a latency of 6 cycles, while the <a href="https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=SSE2&amp;expand=4690" rel="nofollow">intel intrinsic guide</a> says that <code>pshufd</code> only has a latency of 1 cycles. This sounds like great preference to <code>pshufd</code>. However, This instruction is truly for packed integers. When using it for packed doubles, will there be any penalty associated with "wrong type"?</p>

<p>As a similar question, I also heard that instruction <code>movaps</code> is 1-byte smaller than <code>movapd</code>, and they do the same thing by reading 128bits from a 16-bit aligned address. So can we always use the former for move (between XMMs) / load (from memory) / store (to memory)? This seems crazy. I think there must be some reason to reject this. Can someone give me an explanation? Thank you.</p>