[PATCH] Add support to promote f16 to f32

Ahmed Bougacha ahmed.bougacha at gmail.com
Thu Apr 2 14:21:45 PDT 2015


On Thu, Apr 2, 2015 at 2:10 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote:
> ================
> Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:1982
> @@ +1981,3 @@
> +  // Round promoted float to desired precision
> +  SDValue Round = GetPromotedValue(DAG, TLI, Op, NVT, VT, dl);
> +  // Promote it back to the legal output type
> ----------------
> pirama wrote:
>> ab wrote:
>> > I don't follow.  This is about rounding to integers, and has nothing to do with FP, right?  Why not simply GetPromotedFloat?  Or, for that matter, just reusing PromoteFloatRes_UnaryOp.
>> I couldn't find any documentation or reference for this opcode code.  So, I assumed it was similar to float rounding, while at the same time wondering the difference between FROUND and FTRUNC.  I'll reuse PromoteFloatRes_UnaryOp for FTRUNC.
>>
>> The above function still applies to FROUND.  I am trying to trim the extra precision as this node be an explicit operation to reduce precision.
> So, FP_ROUND is the opcode used to do fp->fp rounding (i.e., trim the extra precision).  FTRUNC and FROUND are equivalent to the trunc and round libm functions, i.e., rounding to integer.  IIRC the difference is that one rounds to infinity, and the other to zero.  (-0.1 -> -1 vs 0).

(my comment about the rounding bit doesn't make sense, it's zero vs
nearest, and the example is stupid too, round(-0.1) is 0 as well;
-0.6 is a better example)

-Ahmed

> ================
> Comment at: lib/CodeGen/SelectionDAG/LegalizeTypes.h:512
> @@ +511,3 @@
> +
> +  SDValue GetPromotedFloat(SDValue Op) {
> +    SDValue &PromotedOp = PromotedFloats[Op];
> ----------------
> pirama wrote:
>> ab wrote:
>> > Move this to the .cpp?
>> I'll leave it here to be consistent with the other GetPromotedInteger and similar functions in this file.
> Fair enough,  I asked because I scrolled up a bit to see whether the others did the same.  I saw GetExpandedFloat was in the .cpp, but I was too quick to assume they would be consistent.  Either way I'm fine;  a follow-up patch to put them consistently in one or the other would be nice.
>
> http://reviews.llvm.org/D8755
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>




More information about the llvm-commits mailing list