]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
Fix operand / result types of Iop_DivU128[E], Iop_ModU128 and their signed counterparts
authorFlorian Krohm <flo2030@eich-krohm.de>
Wed, 9 Jul 2025 20:15:46 +0000 (20:15 +0000)
committerFlorian Krohm <flo2030@eich-krohm.de>
Wed, 9 Jul 2025 20:15:46 +0000 (20:15 +0000)
In libvex_ir.h these IROps are described to operate on Ity_I128 operands and produce a like typed result. This contradicts the specification in ir_defs.c
(function typeOfprimop) which claims Ity_V128 for operands and result.

Above IROps are used exclusively by ppc for the following opcodes:
Iop_DivU128  --> vdivuq  Vector Divide Unsigned Quadword
Iop_DivS128  --> vdivsq  Vector Divide Signed Quadword
Iop_DivU128E --> vdiveuq Vector Divide Extended Unsigned Quadword
Iop_DivS128E --> vdivesq Vector Divide Extended Signed Quadword
Iop_ModU128  --> vmoduq  Vector Modulo Unsigned Quadword
Iop_ModS128  --> vmodsq  Vector Modulo Signed Quadword

Reading the ISA document, it is clear, that those opcodes perform an
integer division / modulo operation. Technically, they work on vector
registers, presumably because vector registers are the only resource
wide enough to store a quadword. Perhaps that is where the confusion
comes from.
So Ity_I128 it is.

VEX/priv/ir_defs.c

index 9e7fbf920ef4c1bcdd6f1922fba2a140964c295c..ba61758d74d326a97fac355207dd2f7f3c73c47e 100644 (file)
@@ -3694,10 +3694,12 @@ void typeOfPrimop ( IROp op,
       case Iop_MulI128by10E:
       case Iop_MulI128by10ECarry:
       case Iop_PwExtUSMulQAdd8x16:
-      case Iop_DivU128: case Iop_DivS128:
+         BINARY(Ity_V128,Ity_V128, Ity_V128);
+
+      case Iop_DivU128:  case Iop_DivS128:
       case Iop_DivU128E: case Iop_DivS128E:
       case Iop_ModU128:  case Iop_ModS128:
-         BINARY(Ity_V128,Ity_V128, Ity_V128);
+         BINARY(Ity_I128,Ity_I128, Ity_I128);
 
       case Iop_2xMultU64Add128CarryOut:
       case Iop_Perm8x16x2: