Not sure the denormal handling logic applies for some of the exotic FP types
Details
Diff Detail
Event Timeline
Nine of the really exotic formats I know (the FP8 series) have type-level representations in LLVM unless I missed something ... and for them it's fptrunc I'd be worried about, not fpext
But also, I don't think the "abnormals extend to normals" property is true for bfloat -> float, since a bfloat is an IEEE float with the bottom 16 bits of the mantissa cut off.
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4627–4631 | If the mantissa is sufficiently long, then a subnormal could still be a subnormal in a number with longer range. While this holds true for all the >=16-bit fp types, I'm not sure this holds true for the different FP8 types. |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4627–4631 | I missed fltSemantics::isRepresentableBy (don't understand why fltSemantics is treated so opaquely) |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4627–4631 | Which also seems to not behave as expected for the bf16->f32 case |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4627–4631 | Which would be because it doesn't have the same purpose |
Move condition into APFloat. Take a stab at guarding against exotic formats with large mantissas, although I don't think this is a practical problem (if the precision isn't larger, should fpext even be a valid operation to perform)?
ping, this is the most annoying of the set since the APFloat touch triggers large rebuilds
If the mantissa is sufficiently long, then a subnormal could still be a subnormal in a number with longer range. While this holds true for all the >=16-bit fp types, I'm not sure this holds true for the different FP8 types.