s390: Remove unreachable break statements.
Spotted and fixed by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).


git-svn-id: svn://svn.valgrind.org/vex/trunk@2651 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Fix implementation of the DFP integer operands.

The implementation of integer operands doesn't really match the documentation
for the Iop. Take for example Iop_ExtractExpD64. It is documented as
D64 -> I64 but the implementation of the UNARY is defined as
UNARY(Ity_D64, Ity_D64). The result is an integer that is stored in an integer
format in a floating point register. On the IBM s390 however, the architecture
stores the integer value in a general purpose register (GPR) not a floating
point register. This issue exists with the implementation of 11 Iops where the
PPC implementation has either a source or destination whose value is an integer
but the value is stored in a floating point register in an integer format. After
reviewing the PPC implementation with the s390 developer, it was agreed the
cleanest way to fix this is to change the PPC implementation. The BINOP will be
changed to be consistent with the Iop description. This means the PPC
instruction implementation of the PPC instruction in guest_ppc_toIR.c will need
to reinterpret integer source operands as integers which will move the value
from a floating point register to an integer register before calling binop().
The underlying PPC implementation of the unop() for the specific Iop will also
need to change to move the value from the integer register back to the floating
point register so the native instruction can be issued with the integer value
in a floating point register. It was decided that making the changed in PPC,
rather then having the s390 reinterpret integers as DFP and then move the value
back to an integer register, was preferable as it makes the implementation of
the unop(), binops(), triop() consistent with the definition of the Iop.

This patch also includes the needed changes for the vbit tester.  The Iop
definitions in memcheck/tests/vbit-test/util.c had to be updated to be consitent
with the changes in the Iops as documented below.  Also, the function mkLazy3()
in memcheck/mc_translate.c had to be updated to handle the I32 x I8 x I64 -> I64
and I32 x I8 x I128 -> I128 cases.

The specific list of changes are as follows:

Iop name in pub/libvex_ir.h
   documented type
     type of UNARY/BINARY/TERNARY in priv/ir_defs.c
-------------------------------------------------------

Iop_ExtractExpD64
   D64 -> I64
      UNARY(Ity_D64, Ity_D64); (current)
      UNARY(Ity_D64, Ity_I64); (fix)
 

Iop_ExtractExpD128
   D128 -> I64
       UNARY(Ity_D128, Ity_D64); (current)
       UNARY(Ity_D128, Ity_I64); (fix)

Iop_InsertExpD64
   I64 x I64 -> D64
   I64 x D64 -> D64 (fix definition)
       BINARY(Ity_D64,Ity_D64, Ity_D64); (current)
       BINARY(Ity_I64,Ity_D64, Ity_D64); (fix)

Iop_InsertExpD128
    I64 x I128 -> D128
    I64 x D128 -> D128 (fix definition)
        BINARY(Ity_D64,Ity_D128, Ity_D128); (current)
        BINARY(Ity_I64,Ity_D128, Ity_D128); (fix)

Iop_I64StoD128
    I64S -> D128
        UNARY(Ity_D64, Ity_D128); (current)
        UNARY(Ity_I64, Ity_D128); (fix)

Iop_D64toI64S
    IRRoundingModeDFP(I32) x D64 -> I64
        BINARY(ity_RMode, Ity_D64, Ity_D64) (current)
        BINARY(ity_RMode, Ity_D64, Ity_I64) (fix)

Iop_D128toI64S
    IRRoundingModeDFP(I32) x D128 -> I64
        BINARY(ity_RMode, Ity_D128, Ity_D64); (current)
        BINARY(ity_RMode, Ity_D128, Ity_I64); (fix)

Iop_I64StoD64
    IRRoundingModeDFP(I32) x I64 -> D64
        BINARY(ity_RMode, Ity_D64, Ity_D64); (current)
        BINARY(ity_RMode, Ity_I64, Ity_D64); (fix)

Iop_SignificanceRoundD64
    IRRoundingModeDFP(I32) x I8 x D64 -> D64
        TERNARY(ity_RMode,Ity_D64,Ity_D64, Ity_D64); (current)
        TERNARY(ity_RMode,Ity_I8,Ity_D64, Ity_D64); (fix)

Iop_SignificanceRoundD128
    IRRoundingModeDFP(I32) x I8 x D128 -> D128
         TERNARY(ity_RMode,Ity_D128,Ity_D128, Ity_D128); (current)
         TERNARY(ity_RMode,Ity_I8,Ity_D128, Ity_D128); (fix)

The patch is for bugzilla 311100

git-svn-id: svn://svn.valgrind.org/vex/trunk@2652 8f6e269a-dfd6-0310-a8e1-e2731360e62c