This is an alternative to D64662 that shares more code between
strict and non-strict nodes. It's modeled after the implementation
that I did for softening.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Otherwise, this all looks good to me.
llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp | ||
---|---|---|
1405 | Do we need to short-circuit this if the source type is already double (like below in the FP_ROUND case)? | |
1759 | I guess this isn't fully correct in the strict case: we should raise an "inexact" exception if the Lo part is nonzero. On the other hand, the whole ppc_fp128 arithmetic isn't IEEE compliant anyway (and the libcall impementations ignore exceptions AFAIK), so we probably don't care. |
llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp | ||
---|---|---|
1405 | We do. The test accidentally worked without failing because isel isn't doing full type checking of this pattern def : Pat<(f64 (fpextend f32:$src)), (COPY_TO_REGCLASS $src, SPERC)>; } The type constraint says the input must be smaller than the output and f32 is the only legal type smaller than f64. So I think it just checked the f64 result type and skipped the input type check. |
-Bypass the node in STRICT_FP_EXTEND if the expanded VT matches in the put VT.
-Add a bunch of asserts to getNode to ensure we don't create bad STRICT_FP_EXTEND/STRICT_FP_ROUND.
Do we need to short-circuit this if the source type is already double (like below in the FP_ROUND case)?