将浮动从高xmm四字移动到低xmm四字

Question

MOVHPD extracts high quadword of an xmm register into memory.

PEXTRQ extracts the high quadword of an xmm register and places it into an integer register (integers only).

SHUFPD shuffles.

VPSLLDQ causes the high quadword to be zeroed out.

Is there an instruction to move a floating-point value from the high quadword of an xmm register into the low quadword of the same xmm register or another xmm register? Or do I always have to go through memory (adding extra cycles)?

UPDATE: Based on comments below by @fuz and @Peter Cordes, here's what I did. This calls a rounding function for the low and high quadwords of xmm0 individually; due to special rounding parameters, the function must be called for each qword individually, so it can't be a SIMD instruction. The goal is to round each of the qwords in xmm0 and put the result in xmm11.

movapd xmm2,xmm0 ;preserve both qwords of xmm0
call Round
movsd [scratch_register+0],xmm0 ; write low qword to memory
movhlps xmm0,xmm2
call Round
movsd [scratch_register+8],xmm0 ; write low qword to memory
movupd xmm11,[scratch_register]

UPDATE #2: @Peter Cordes showed how to do this without memory:

movhlps  xmm2, xmm0   ; extract high qword for later
call Round            ; round the low qword
movaps   xmm3, xmm0   ; save the result
movaps   xmm0, xmm2   ; set up the arg
call Round            ; round the high qword
movlhps  xmm3, xmm0   ; re-combine into xmm3

Answer 1

See Agner Fog's asm optimization guide , his chapter on SIMD has a table of shuffle instructions different kinds of data movement that will give you a small number of instructions to think about (or look up in Intel's manuals if you don't remember exactly what they do) and see if they're what you want.

---

The cheapest way to broadcast the high qword of a register to both elements is movhlps xmm0,xmm0 . (Or for integer data if your code might run on Nehalem, use punpckhqdq xmm0,xmm0 to avoid FP<->vec-int bypass delays.)

Without AVX, movhlps is nice because it does a slightly different shuffle than unpckhpd .

• movhlps xmm3, xmm4 does xmm3[0] = xmm4[1]; , leaving xmm3[1] unchanged.
• unpckhpd xmm3, xmm4 takes the high qwords from xmm3 and xmm4 and puts them in xmm3 in that order. So in the destination, the high qword moves to low, then the high qword from the src is copied over. xmm3[0] = xmm3[1]; xmm3[1] = xmm4[1]

But unpcklpd is useless, it's 1 byte longer and does the same thing as SSE1 movlhps . (copy low qword from the src to the high qword of the destination, leaving the low qword of the destination unmodified.) Same for movapd , always use movaps instead.

Also re: code-size: it costs a REX prefix to use xmm8..15, so choose your register allocation to use xmm8..15 in as few instructions as possible (or ones that already need a REX prefix, eg for a pointer in r8..15). Code-size isn't usually a big deal, but all else equal smaller is normally best. Smaller instructions normally pack better into the uop cache.

---

With AVX, you can use vunpckhpd with either order of source operands , with the first src's high qword going to the low qword of the destination. There's no code-size advantage (or other perf advantage) for vmovhlps , they can both use a 2-byte VEX prefix for a minimum instruction size of 4 bytes.

eg vunpckhpd xmm0, xmm1, xmm0 is like vmovhlps xmm0, xmm0,xmm1 .

---

You could use shufpd or vpshufd for the problem you're trying to solve. It's a waste of code size because it needs an immediate, but apparently you didn't realize that you can use shufpd xmm0, xmm0, 0b11 to take (in this order):

• the low qword from xmm0[1] (first src operand, low bit of the immediate)
• the high qword from xmm0[1] (second src operand, high bit of the immediate).

The shuffle control can read the same input element multiple times.

---

Interestingly, the NASM compiler will compile VUNPCKHPD with only two operands

NASM allows you to write instructions like vaddps xmm0, xmm0, xmm1 as vaddps xmm0, xmm1 , omitting the separate destination operand when it's the same as the first source.

I'm puzzled because these values are double precision, not single, but it works.

Everything is just bits/bytes to be copied around . Unless you're using a FP computation instruction (eg like addpd / addps ), the "type" doesn't matter. (You can tell by the presence or absence of a "SIMD Floating-Point Exceptions" section in the manual entry whether it cares about the meaning of the bits as an FP bit pattern or not. eg addps : https://www.felixcloutier.com/x86/addps#simd-floating-point-exceptions . (But there aren't any surprises. The only instructions that do care do so for very obvious reasons, like doing FP computation or type conversion, not just copying data around.)

No real CPUs care about PS vs. PD instructions for performance, but some care about vec-int vs. vec-FP, so unfortunately it's not always a win to use pshufd to copy-and-shuffle FP data. Or to use shufps as a 2-source integer shuffle.

Unfortunately before AVX512 there aren't general-purpose 2-source "integer" shuffles, only palignr and punpck instructions. And before AVX, there aren't FP copy-and-shuffle instructions. (And ironically, vpermilps with an immediate is redundant vs. vshufps dst, same,same, imm8 except for a memory-source load+shuffle, and should be avoided for code-size reasons. What's the point of the VPERMILPS instruction (_mm_permute_ps)? )

---

  movapd xmm2,xmm0 ;preserve both qwords of xmm0
  call Round
     movsd [scratch_register+0],xmm0 ; write low qword to memory
  movhlps xmm0,xmm2
  call Round

This is efficient shuffling, but unfortunately it creates a false dependency between the output of the first Round and the input to the 2nd . So the two calls can't work in parallel. Instead, shuffle as you copy before the first call, preferably into a register you know has been "dead" for a while or was part of the dependency chain for the value in xmm0 so must be ready before it.

  movhlps  xmm2, xmm0   ; extract high qword for later
  call Round                ; round the low qword
  movaps   xmm3, xmm0   ; save the result
  movaps   xmm0, xmm2   ; set up the arg
  call Round                ; round the high qword
  movlhps  xmm3, xmm0    ; re-combine into xmm3

Unless you're running low on registers that your hand-written Round function doesn't touch, you don't particularly need memory and it's not more efficient.

As a bonus, all of those movaps and movhlps instructions are only 3 bytes long, and there's the same number of them as there are instructions in your version.

Another option (especially if your input was in a different register to start with) would be to Round the high half first, then you could put the high half back into xmm0 with movlhps .

And BTW, if you have SSE4.1, roundpd can round to nearest integer with Nearest, towards +-Inf (ceil/floor), or towards 0 (truncation).

---

movsd [scratch_register+8],xmm0 ; write low qword to memory
movupd xmm11,[scratch_register]

Never do this, narrow store + wide reload is a guaranteed store-forwarding stall. (~10 cycles extra latency).

Use a 16-byte aligned storage location (eg on the stack at [rsp+8] or something), and
unpckhpd xmm0, [scratch_register] to load+shuffle .

Unfortunately Intel designed memory-source unpck instructions badly, so they require a 16-byte memory source, not just the 8 bytes they actually load/use. There are several cases where the