aboutsummaryrefslogtreecommitdiff
path: root/llvm/utils/UpdateTestChecks/common.py
diff options
context:
space:
mode:
authorLuke Lau <luke@igalia.com>2024-10-07 17:40:32 +0800
committerGitHub <noreply@github.com>2024-10-07 17:40:32 +0800
commitc98e41f8586bc43033d29ef3ec0f9a2f79b3ec32 (patch)
treef62c4eb54a597214fa728fb2e39c9b59d1d7fbe0 /llvm/utils/UpdateTestChecks/common.py
parent3137b6a263d2549a520690606e286ab4c8e3c9e5 (diff)
downloadllvm-c98e41f8586bc43033d29ef3ec0f9a2f79b3ec32.zip
llvm-c98e41f8586bc43033d29ef3ec0f9a2f79b3ec32.tar.gz
llvm-c98e41f8586bc43033d29ef3ec0f9a2f79b3ec32.tar.bz2
[LegalizeVectorTypes] Always widen fabs (#111298)
fabs and fneg are similar nodes in that they can always be expanded to integer ops, but currently they diverge when widened. If the widened vector fabs is marked as expand (and the corresponding scalar type is too), LegalizeVectorTypes thinks that it may be turned into a libcall and so will unroll it to avoid the overhead on the undef elements. However unlike the other ops in that list like fsin, fround, flog etc., an fabs marked as expand will never be legalized into a libcall. Like fneg, it can always be expanded into an integer op. This moves it below unrollExpandedOp to bring it in line with fneg, which fixes an issue on RISC-V with f16 fabs being unexpectedly scalarized when there's no zfhmin.
Diffstat (limited to 'llvm/utils/UpdateTestChecks/common.py')
0 files changed, 0 insertions, 0 deletions