[llvm-commits] [PATCH][APFloat] add APFloat::isDenormal()

Shuxin Yang shuxin.llvm at gmail.com
Mon Jan 7 10:14:37 PST 2013


Thanks!

Shuxin
On 1/7/13 7:22 AM, Ulrich Weigand wrote:
> Hal Finkel <hfinkel at anl.gov> wrote on 02.01.2013 21:28:13:
>
>> ----- Original Message -----
>>> From: "Shuxin Yang" <shuxin.llvm at gmail.com>
>>> To: "l >> Commit Messages and Patches for LLVM"
> <llvm-commits at cs.uiuc.edu>
>>> Sent: Wednesday, January 2, 2013 12:45:29 PM
>>> Subject: [llvm-commits] [PATCH][APFloat] add APFloat::isDenormal()
>>>
>>> Hi,
>>>
>>>       The attached tiny patch is to add APFloat::isDenormal() to
>>>       APFloat
>>> class.
>>> Only the changes to APFloat.{cxx,h} are relevant, the rest are test
>>> to
>>> see if it works.
>>>
>>>      As far as I can tell, a APFloat is a denormal if it satisfies
>>> following conditions:
>>>     1. it is not zero/infinity/nan (i.e APFloat::isNormal() == ture)
>>>     2. the exponent field take the minimal value
>>>     3. the most-significant-bit of the mantissa bit is 0
>>>
>>>     I think condition-3 implies 2). However, in my change I still test
>>> these three conditions.
>>> The rationale is twofold: condition-2 is cheap to verify and testing
>>> 2)
>>> would likely yields
>>> early-exist.
>>>
>>>      The "test" is hard-coded in the InstCombineAddSub.cpp (this part
>>>      is
>>> not going to be committed).
>>> and the test is triggered by any *.ll having a fadd instruction.
>>>
>>>      The "test" covers the tricky cases about
>>> single/double/quadruple-precision as well as Intel 80-bit
>>> double-ext precision floating-point. I don't know how to test PPC FP.
>>> But I don't think it is necessary
>>> to test PPC FP as APFloat is a arch-neutral representations of all
>>> these
>>> formats.
>> I've cc'd Ulrich Weigand (who has most-recently worked on PPC FP128
>> support). I agree that testing PPC FP here can be omitted for now.
>> For one thing, what the function should do may depend on how it is
>> going to be used. PPC FP is really the sum of two doubles, but we
>> currently approximate it (in the same way as gcc does) as one larger
>> IEEE-like number.
> I agree that the implementation makes sense for PPC FP128 too;
> the approximation used in APFloat follows standard IEEE rules,
> and the choice of "-1022 + 53" for minimum exponent in that
> approximation implies that numbers will be considered "denormal"
> if the double-double pair can represent less than the usual
> 106 bits of mantissa.  (This does not necessarily imply that
> either of the two doubles of the pair, when encoded into the
> actual target format, is themselves denormal.)
>
> Bye,
> Ulrich
>




More information about the llvm-commits mailing list