[Valgrind-developers] Proposal to add types for DFP support

[John R. <jr...@bi...>]

On 01/11/2012 10:52 AM, Carl E. Love wrote:
[snip]
>> AFAICS (also, from reading the rest of the doc) you want three new types, 
>> Ity_D32, Ity_I64 and Ity_D128.  (yes? that sounds right to me)
> 
> The addition of new types is not required.  In the proposal the type D32, D64 
> and D128 was used to make it clear that the Iops operate on DFP values stored 
> in a floating point registers.  From an implementation standpoint, the Iops 
> can be implemented using the existing F32, F64 and F128 types.  I did a proof
> of concept implementation for a couple of Iops by explicitly adding the D64 
> and D128 types.  I have implemented most of the 49 POWER instructions just using
> the existing floating point types.  Adding the DFP types requires adding more 
> code to handle unop, binop, triops of DFP values.  If the Iops are implemented 
> using the F32, F64 and F128 types, then the existing code to handle the various 
> unop, binop and triop cases can be leveraged minimizing the amount of additional 
> code. For example, we don't need new binop code to handle two DFP operands, we 
> just leverage the existing binop code that handles two floating point operands.  
> Not adding DFP types will minimize the amount of additional code that is 
> functionally similar to existing code.  Adding the DFP type may provide 
> additional capability for type checking. I am not sure how much value there 
> is in this additional type checking capability.  Input on this point from the 
> community would be good.

For binary floating point, memcheck currently tracks undefined bits very coarsely.
If at least one bit of input is Undefined, then every bit of output is Undefined.
This coarseness is independent of the operation [except perhaps for a Copy operation],
independent of the field (sign, exponent, significand), and independent of the
positional value of the Undefined bit(s) within the field.

I am disappointed by the current coarseness of tracking Undefined bits for
binary floating point, and I am saddened that tracking for decimal floating point
may inherit similar coarseness.  This will produce visible practical limitations
in the Usability of memcheck for decimal floating point.  For instance, consider
US retail transactions.  There is a big difference between an Undefined which
affects "only" the cents ($0.01) versus an Undefined which affects the thousands
of dollars ($1,000.00).  Furthermore, the cents column can be _more_ important.
The decline in effective value of a one-cent coin ("penny": $0.01) has produced
serious proposals for "nickel rounding" (round the total of several items
to a multiple of $0.05), and this has high impact for grocery stores and other
retailers with a large number of small transactions.

So, please introduce a type corresponding to each Decimal Floating Point
data format, the better to encourage more accurate tracking of Undefined
bits in DFP operations.


[By the way, memcheck understands only partially the propagation of
Undefined bits through two's complement binary integer ADD and SUBtract!
Current code believes that an Undefined input bit always "pollutes" any
result bit that has equal or greater significance ("to the left"),
which ignores the fact that Carry does not propagate when there are
enough Defined zero bits at matching positional values.  Most of the
ugliness for memcheck suppressions of false positives in string operations
(strlen, etc.) is a direct result of memcheck not understanding the
details of propagation of Undefined in a data-dependent Carry chain.]

--