Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
| Time | Test | |
|---|---|---|
| 140 ms | linux > Polly.ScopInfo::Unknown Unit Message (" ") Script:
--
: 'RUN: at line 1'; opt -polly-process-unprofitable -polly-remarks-minimal -polly-use-llvm-names -polly-import-jscop-dir=/mnt/disks/ssd0/agent/llvm-project/polly/test/ScopInfo -polly-codegen-verify -basic-aa -scoped-noalias -tbaa -polly-scops -analyze < /mnt/disks/ssd0/agent/llvm-project/polly/test/ScopInfo/memcpy-raw-source.ll
|
Event Timeline
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26202 | I have no idea why FLT_ROUNDS calls TFI.getStackAlignment() to get the second parameter here. It should just be 4. | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26202 | Changed here but implementation of LowerFLT_ROUNDS_ was not changed. | |
It is still needed. This patch depends on D74729. Next steps, like support in frontend (as fesetround) and lowering on other platforms make sense only after destiny of these patches will be determined.
The motivation for this work is implementation of a pragma that would set/restore rounding mode without need to call fesetround.
| llvm/test/CodeGen/X86/fpenv.ll | ||
|---|---|---|
| 4 | regenerate with the update_llc_test_checks.py script? | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26233–26234 | Is this enforced elsewhere? (verifier, etc) | |
| llvm/lib/Target/X86/X86ISelLowering.h | ||
| 835–836 | I suspect this is backwards, and should say that glibc choose to use values compatible with the ones stored in FPSR. | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26233–26234 | It is not an error handling, it is an assertion check. This intrinsic is a low-level entity and is actually only a wrap over an instruction that writes to control register. It is responsibility of a caller to ensure that argument of this intrinsic is valid. A check in verifier is possible but is not much helpful, because the argument may be a runtime expression. | |
| llvm/lib/Target/X86/X86ISelLowering.h | ||
| 835–836 | Updated the comment. | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26211 | I think we cannot assume x87 is always available https://godbolt.org/z/4MbsarMcP. GCC supports nox87 feature, @LiuChen3 is doing the same thing in LLVM in D100091. | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26211 |
Is there an x86 core that does not support x87 instructions? If no, then -mno-80387, similar to -msoft-float and -mgeneral-regs-only are proposed for the cases like Linux kernel, where access to FP hardware is undesirable because the modification of FP state requires saving/restoring it in process context. As set_rounding by essence modifies FP state, -mno-80387 is identical to -msoft-float. By the way, GCC documentation list them as synonyms (https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html).
I added checks for soft-float in constructor of X86TargetLowering. If this option is effect, this function is not used for lowering of set_rounding. | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26211 | I think Core and most Atom support x87 instructions. Someone mentioned there're some targets for IoT don't. https://retrocomputing.stackexchange.com/a/9662 | |
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26211 | Interesting reference, thank you. It is still true that if hardware supports FP operations, it supports x87 also. There is no a processor that supports FP in hardware but do not support x87. So we do not need to check for x87 presence here, it should be enough to enable or not custom lowering in the constructor of X86TargetLowering. I added the check for Subtarget.hasX87() to support -mno-80387 also. | |
This patch LGTM, but I'd like other sign off.
| llvm/lib/Target/X86/X86ISelLowering.cpp | ||
|---|---|---|
| 26211 | Makes sense to me, thanks. | |