__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
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Time | Test | |
---|---|---|
940 ms | x64 windows > MLIR.Examples/Toy/Ch6::jit.toy Script:
--
: 'RUN: at line 1'; toyc-ch6 -emit=jit C:\ws\w1\llvm-project\premerge-checks\mlir\test\Examples\Toy\Ch6\jit.toy
| |
4,900 ms | x64 windows > MLIR.Examples/Toy/Ch7::jit.toy Script:
--
: 'RUN: at line 1'; toyc-ch7 -emit=jit C:\ws\w1\llvm-project\premerge-checks\mlir\test\Examples\Toy\Ch7\jit.toy
|
Event Timeline
Comment Actions
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.
Comment Actions
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? |