__builtin_isinf currently generates a floating-point compare operation
which triggers a trap when faced with a signaling NaN in StrictFP mode.
This commit uses integer operations instead to not generate any trap in
such a case.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
System/Z's TEST DATA CLASS instruction covers most (all?) of the possible FP value states. You might want to subscribe, or add as a reviewer, jonpa just to make sure everyone stays in sync.
Thanks for keeping me updated on this - I see that you have already included the testFPKind() hook, so I will add these opcodes to SystemZ once this is committed...
clang/test/CodeGen/builtin_float_strictfp.c | ||
---|---|---|
21 | Am I right to think that clang should not use llvm.convert here since it's a constrained operation? Any idea why that happens? |
Ping?
clang/test/CodeGen/builtin_float_strictfp.c | ||
---|---|---|
21 | Nvm, that's for when fp16 is not supported. I'm guessing this ought to not throw an exception. |
Requesting review since the logic has changed. This time I've also tested isfinite against glibc's result. All looks good.
Am I right to think that clang should not use llvm.convert here since it's a constrained operation? Any idea why that happens?