This is an archive of the discontinued LLVM Phabricator instance.

[FPEnv] [PowerPC] Alternative lowering ppc_fp128 StrictFP Nodes to libcalls

Authored by craig.topper on Nov 29 2019, 9:12 PM.



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.

Diff Detail

Event Timeline

craig.topper created this revision.Nov 29 2019, 9:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 29 2019, 9:12 PM

Otherwise, this all looks good to me.


Do we need to short-circuit this if the source type is already double (like below in the FP_ROUND case)?


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.

craig.topper marked an inline comment as done.Dec 3 2019, 11:06 AM
craig.topper added inline comments.

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)),



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.

uweigand accepted this revision.Dec 3 2019, 12:01 PM

Except for what appears to be a typo below, this LGTM.


"type type"?



This revision is now accepted and ready to land.Dec 3 2019, 12:01 PM
This revision was automatically updated to reflect the committed changes.