aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
diff options
context:
space:
mode:
authorMatt Arsenault <Matthew.Arsenault@amd.com>2022-12-06 09:16:27 -0500
committerMatt Arsenault <arsenm2@gmail.com>2023-02-05 07:02:18 -0400
commitd4f38ef288c3a4cf2318182c8585a5c7e760877a (patch)
tree583fdc5a7797b45fbd0e766a3ac8f78d971631d8 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
parent8c5a292202ff26ad51cf348001f82444d96e803b (diff)
downloadllvm-d4f38ef288c3a4cf2318182c8585a5c7e760877a.zip
llvm-d4f38ef288c3a4cf2318182c8585a5c7e760877a.tar.gz
llvm-d4f38ef288c3a4cf2318182c8585a5c7e760877a.tar.bz2
LangRef: Clarify behavior of llvm.is.fpclass with "denormal-fp-math"
This does not read canonicalized values, which matches the behavior of the basic DAG expansion using integer operations. There is a buggy expansion using FP-operations if legal which needs to be adjusted to account for this. We need to be aware of the denormal mode to switch between is.fpclass calls and fcmp. There's no real spec for denormal handling anywhere, but I believe this is the most harmonious way to deal with the question considering the requirement to not quiet input signaling nans. This matches the behavior of MSVC's _fpclass and AMDGPU's v_cmp_class_f32. fpclassify currently does not use this, and has inconsistent behavior for denormals under DAZ on different platforms (i.e. clang and gcc report FP_ZERO return FP_ZERO for a denormal under DAZ, MSVC reports FP_SUBNORMAL).
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions