Questions about X86_INS_MUL/X86_INS_DIV translation

I noticed that in the translation results of bin2llvmir, the integer type of udiv/mul operators are different from source code. For example, i64 integer will become i128 integer:

```
%tmp8 = udiv i64 9223372036854775807, %blocksize
```

becomes

```
%tmp16 = udiv i128 9223372036854775807, %arg4
```

In `Capstone2LlvmIrTranslatorX86_impl::translateDiv`, the translation rules are like:

```
case 8:
{
op0l = X86_REG_RAX;
op0h = X86_REG_RDX;
divR = X86_REG_RAX;
remR = X86_REG_RDX;
divT = irb.getInt128Ty();
resT = irb.getInt64Ty();
break;
}
```

I wonder why you use such design, because we cannot get the int64_t value from i128 value by using `getZExtValue()`, I tried to change `divT = irb.getInt128Ty();` to `divT = irb.getInt64Ty();`. But the result becomes:

```
%tmp16 = udiv i64 -1, %arg4
```

which is 18446744073709551615 when using getZExtValue.

However, if I change type for both `divT` and `resT`, the result is the same as source code:

```
%tmp16 = udiv i64 9223372036854775807, %arg4
```

Do you have any thoughts on that, thank you.

The relevant entry point is Capstone2LlvmIrTranslatorX86_impl::translateDiv, especially the case 8 rules shown in the issue. Reproduce the i64 MUL/DIV translation with bin2llvmir and compare the generated IR and getZExtValue behavior for the i128 and i64 variants. Done means documenting or correcting the type choice so the generated result preserves the source value.

Written by the indexing model from the issue text.