# MOVQ xmm,xmm source incorrectly modeled as 128-bit

**URL:** <https://community.hex-rays.com/t/movq-xmm-xmm-source-incorrectly-modeled-as-128-bit/797>\
**Category:** Bugs\
**Created:** [September 11, 2026, 6:08am UTC](https://community.hex-rays.com/t/movq-xmm-xmm-source-incorrectly-modeled-as-128-bit/797 "2026-09-11T06:08:57Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![QuietMaple10](https://avatars.discourse-cdn.com/v4/letter/q/50afbb/32.png) [@QuietMaple10](https://community.hex-rays.com/u/QuietMaple10)\
**Post date:** [September 11, 2026, 6:08am UTC](https://community.hex-rays.com/t/movq-xmm-xmm-source-incorrectly-modeled-as-128-bit/797/1 "2026-09-11T06:08:57Z")

</div>

Given the following minimal example:

```x86asm
; __m128i__ fastcall repro(__int64 dummy, double x);
repro:
    movq xmm0, xmm1 ; F3 0F 7E C1
    ret

```

Hex-Rays correctly determines:

```x86asm
__m128i__ fastcall repro@<xmm0>(
    __int64@<rcx>,
    double@<xmm1>
)

```

However, at `MMAT_GENERATED`, it produces:

```plaintext
USE: xmm1.16
DEF: xmm0.16

mov call !_mm_move_epi64<fast:__m128i xmm1.16>
    => __m128i .16, xmm0.16
    ; u=xmm1.16 d=xmm0.16

```

At `MMAT_LVARS`, the 8 byte argument has effectively become a 16 byte intrinsic input:

```plaintext
mov call !_mm_move_epi64<fast:__m128i x.16>
    => __m128i .16{1}, result.16{1}
    ; u=xmm1.16 d=xmm0.16

```

Resulting in:

```cpp
// local variable allocation has failed, the output may be wrong!
__m128i__ fastcall repro(__int64 dummy, double x)
{
    return _mm_move_epi64(*(__m128i *)&x);
}

```

For `MOVQ` with XMM source and destination operands, only the low 64 bits of the source are read, the low 64 bits are copied to the destination and the upper 64 bits of the destination are cleared.

I would therefore expect the use list for this instruction to cover only the low 8 bytes of the source register, such that `USE: xmm1_8.8`

As far as I can tell this is specific to the XMM/XMM lift, XMM/r64 uses `xmm0_8.8` and r64/XMM uses an 8 byte source with a wider zero extended destination.

The same issue appears with both XMM/XMM `MOVQ` encodings.

Thanks for the great product.

---

<div class="post-metadata">

**Author:** ![igor](https://sea2.discourse-cdn.com/flex002/user_avatar/community.hex-rays.com/igor/32/35_2.png) [@igor](https://community.hex-rays.com/u/igor)\
**Post date:** [September 11, 2026, 2:09pm UTC](https://community.hex-rays.com/t/movq-xmm-xmm-source-incorrectly-modeled-as-128-bit/797/2 "2026-09-11T14:09:48Z")

</div>

Thanks, we can confirm the issue! We should have a fix for this in 9.5.