mips: fixing issues spotted by a static code analysis tool

Florian ran a static code analysis tool and found the issues.
Cleaning out old cruft now.


git-svn-id: svn://svn.valgrind.org/vex/trunk@2649 8f6e269a-dfd6-0310-a8e1-e2731360e62c
 The 32-bit DFP value is stored in a 64-bit register in
 ppc. The D32 to D64 and D64 to D32 definitions for the
 Iop type was specified in VEX/priv/ir_defs.c, function
 typeOfPrimop() as:

   case Iop_D32toD64:
      UNARY(Ity_64, Ity_D64);
   case Iop_D64toD32:
      BINARY(ity_RMode, Ity_D64, Ity_D64);

since the values resided in a 64-bit register. As part of the s390 DFP support
the definitions were changed to:

   case Iop_D32toD64:
      UNARY(Ity_32, Ity_D64);
   case Iop_D64toD32:
      BINARY(ity_RMode, Ity_D64, Ity_D32);

to reflect what they really should be. However, this broke the ppc
implementation. Valgrind would fail and report a mismatch on the types as the
ppc code was using a D64 instead of a D32.

This patch adds support for fetching and storing the Dfp32 operand as a 32-bit
value.  The support includes adding the functions iselDfp32Expr() and
iselDfp32Expr_wrk() and additional code to support the DFP32 bit iops.

This patch is for Bugzilla 312620.


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