Semantics of lifted BSWAP operation doesnt match CPU semantics

Version and Platform (required):

• Binary Ninja Version: 5.4.9793-dev Personal, 12373795
• OS: fedora
• OS Version: 44
• CPU Architecture: x86_64

Bug Description:

On x86-64 the instruction bswap ax is architecturally undefined behavior, however a CPU will execute the instruction with the result giving AX=0. BN however will semantically do the swap.

Steps To Reproduce:

    global _start

_start:
    xor rdi,rdi
    mov rax,0xDEADBEEFCAFEBABE
    ;bswap ax
    db 0x66, 0x0F, 0xC8

    ; real cpu:
    ; ax=0 di=0
    cmp ax,di
    je .skip
    inc rdi
.skip:
    ;sys_exit(rdi)
    mov rax, 60
    syscall

Compile with:

nasm -f elf64 testbswap.s 
ld -Ttext 0x400080 -o testbswap testbswap.o
./testbswap ;echo $?
0

Binary ninja will show this as HLIL:

0040009d        syscall(sys_exit {0x3c}, status: 1)

And in Mapped MLIL it's clear the swap is executed:

   1 @ 00400083  rax = 0xdeadbeefcafebabe
   2 @ 0040008d  rax.ax = 0xbeba

Expected Behavior:

Both a real CPU as unicorn/qemu will set AX to 0 for this instruction.

Binary:

cubic iris blooms closely

Additional Information:

The instruction is actually undefined behavior, therefor should not appear in "normal" binaries.

Start with the provided NASM reproduction and compare Binary Ninja's lifted MLIL for the encoded bswap ax instruction against the real CPU, Unicorn, or QEMU behavior. Done means Binary Ninja models the instruction as producing AX=0 rather than performing the byte swap.