diff options
author | Luke Lau <luke@igalia.com> | 2024-10-07 17:40:32 +0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-10-07 17:40:32 +0800 |
commit | c98e41f8586bc43033d29ef3ec0f9a2f79b3ec32 (patch) | |
tree | f62c4eb54a597214fa728fb2e39c9b59d1d7fbe0 /llvm/utils/UpdateTestChecks/common.py | |
parent | 3137b6a263d2549a520690606e286ab4c8e3c9e5 (diff) | |
download | llvm-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