x86_64: strange translation of "vpgatherqq"

Host environment

• Operating system: Linux
• OS/kernel version: 5.15
• Architecture: x86
• QEMU flavor: qemu-x86_64
• QEMU version: 9.0.2
• QEMU command line:

  qemu-x86_64 -d op -D a.out test

Emulated/Virtualized environment

linux-user mode

Description of problem

The translate of instruction "vpgatherqq" is confusing.

It happens when register xmm4 is in the middle, like "vpgatherqq %xmmi,0x0(,%xmm4,1),%xmmj".

Steps to reproduce

1. Make a simple embedded assembly code named test.c:

int main()
{
    asm("vpgatherqq %xmm6,0x123(,%xmm2,4),%xmm7");
    asm("vpgatherqq %xmm6,0x123(,%xmm3,4),%xmm7");
    asm("vpgatherqq %xmm6,0x123(,%xmm4,4),%xmm7");
    asm("vpgatherqq %xmm6,0x123(,%xmm5,4),%xmm7");
    return 0;
}

and compile it:

gcc -o test test.c -static

2. Run it with QEMU, print the micro ops:

qemu-x86_64 -d op -D a.out test

We can get output like this (only contain vpgatherqq):

 ---- 000000000040174d 0000000000000000
 mov_i64 loc2,$0x123
 add_i64 loc14,env,$0x3d0      #This is xmm2
 add_i64 loc16,env,$0x4d0
 add_i64 loc18,env,$0x510
 call vpgatherqq_xmm,$0x0,$0,env,loc18,loc16,loc14,loc2,$0x2
 mov_vec v128,e8,tmp20,v128$0x0
 st_vec v128,e8,tmp20,env,$0x4e0
 mov_vec v128,e8,tmp22,v128$0x0
 st_vec v128,e8,tmp22,env,$0x520

 ---- 0000000000401757 0000000000000000
 mov_i64 loc2,$0x123
 add_i64 loc23,env,$0x410      #This is xmm3
 add_i64 loc25,env,$0x4d0
 add_i64 loc26,env,$0x510
 call vpgatherqq_xmm,$0x0,$0,env,loc26,loc25,loc23,loc2,$0x2
 mov_vec v128,e8,tmp27,v128$0x0
 st_vec v128,e8,tmp27,env,$0x4e0
 mov_vec v128,e8,tmp28,v128$0x0
 st_vec v128,e8,tmp28,env,$0x520

 ---- 0000000000401761 0000000000000000
 mov_i64 loc2,$0x123
 add_i64 loc29,env,$0x310      #This is xmm4 ???
 add_i64 loc31,env,$0x4d0
 add_i64 loc32,env,$0x510
 call vpgatherqq_xmm,$0x0,$0,env,loc32,loc31,loc29,loc2,$0x2
 mov_vec v128,e8,tmp33,v128$0x0
 st_vec v128,e8,tmp33,env,$0x4e0
 mov_vec v128,e8,tmp34,v128$0x0
 st_vec v128,e8,tmp34,env,$0x520

 ---- 000000000040176b 0000000000000000
 mov_i64 loc2,$0x123
 add_i64 loc35,env,$0x490      #This is xmm5
 add_i64 loc37,env,$0x4d0
 add_i64 loc38,env,$0x510
 call vpgatherqq_xmm,$0x0,$0,env,loc38,loc37,loc35,loc2,$0x2
 mov_vec v128,e8,tmp39,v128$0x0
 st_vec v128,e8,tmp39,env,$0x4e0
 mov_vec v128,e8,tmp40,v128$0x0
 st_vec v128,e8,tmp40,env,$0x520

Since the register xmms are continuous within the structure CPUArchState, the offset of xmm2, xmm3, xmm4, xmm5 should be a arithmetic sequence.

From the output, we can infer that the common difference should be 0x40 and the offset of xmm4 should be 0x450 but not 0x310.

I used GDB to track it, the location where the change occurred is:

target/i386/tcg/translate.c, gen_lea_modrm_0(), line 2215:

        if (rm == 4) {
            int code = x86_ldub_code(env, s);
            scale = (code >> 6) & 3;
            index = ((code >> 3) & 7) | REX_X(s);
            if (index == 4) {
                index = -1;  /* no index */
            }
            base = (code & 7) | REX_B(s);
            havesib = 1;
        }

This code turned 4 into -1, and -1 do explain the offset 0x310 (xmm0 has offset 0x350).

Additional information

Monitoring the function "helper_vpgatherqq_xmm" can draw similar conclusions: it used wrong value but not xmm4.