|2,230 ms||x64 debian > libarcher.races::lock-unrelated.c|
Script: -- : 'RUN: at line 13'; /mnt/disks/ssd0/agent/llvm-project/build/./bin/clang -fopenmp -pthread -fno-experimental-isel -g -O1 -fsanitize=thread -I /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests -I /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/src -L /mnt/disks/ssd0/agent/llvm-project/build/lib -Wl,-rpath,/mnt/disks/ssd0/agent/llvm-project/build/lib /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests/races/lock-unrelated.c -o /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/tools/archer/tests/races/Output/lock-unrelated.c.tmp -latomic && env TSAN_OPTIONS='ignore_noninstrumented_modules=0:ignore_noninstrumented_modules=1' /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests/deflake.bash /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/tools/archer/tests/races/Output/lock-unrelated.c.tmp 2>&1 | tee /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/tools/archer/tests/races/Output/lock-unrelated.c.tmp.log | /mnt/disks/ssd0/agent/llvm-project/build/./bin/FileCheck /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests/races/lock-unrelated.c
|0 ms||x64 debian > libomptarget.mapping::declare_mapper_nested_default_mappers_array.cpp|
Script: -- : 'RUN: at line 1'; echo ignored-command
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.
Is this enforced elsewhere? (verifier, etc)
I suspect this is backwards, and should say that glibc choose to use values compatible with the ones stored in FPSR.
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.
Updated the comment.
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.
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.
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.