[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 324894] Phase 3 support for IBM Power ISA 2.07
From:       Julian Seward <jseward () acm ! org>
Date:       2013-09-27 16:31:58
Message-ID: bug-324894-17878-pSRPRued3a () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=324894

--- Comment #7 from Julian Seward <jseward@acm.org> ---
These look fine to me.  Only comment is a sanity check about the
saturating narrowing instructions:

+   case 0x4CE: // vpkudus (Pack Signed Double Word Unsigned Saturate)
+               binop(Iop_QNarrowBin64Uto32Ux4, mkexpr(vA), mkexpr(vB)) );

+   case 0x54E: { // vpksdus (Pack Signed Double Word Unsigned Saturate)
+      putVReg( vD_addr, binop(Iop_QNarrowBin64Uto32Ux4,

+   case 0x5CE: // vpksdss (Pack Signed double word Signed Saturate)
+               binop(Iop_QNarrowBin64Sto32Sx4, mkexpr(vA), mkexpr(vB)) );

The last one is OK, but the first two .. I was wondering if perhaps
they should be using the S-to-U narrowing IROps, instead of the U-to-U
ones as you have here.  I ask because of the description "Signed
Double Word Unsigned Saturate"

In fact, is the text for the first one correct?  Should it be "Pack
Unsigned Double Word Unsigned Saturate" ?  Then the UtoU op is
correct; but the second one still doesn't look right.

Just a sanity check .. I may misinterpret what I see.  These
saturating narrowing ops are indeed tricky.

If it's any help, the exact meaning of the 4 cases (UtoU, UtoS, StoU,
StoS) is documented in libvex_ir.h.  Search for the text "For
saturated narrowing, I believe".

Apart from that sanity check, looks good to land.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]