aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp
diff options
context:
space:
mode:
authorMatt Arsenault <Matthew.Arsenault@amd.com>2020-05-27 09:36:42 -0400
committerMatt Arsenault <arsenm2@gmail.com>2020-07-21 16:17:10 -0400
commit2fe0ea8261cf40d9c1ccdb9af633328290dd925e (patch)
tree77955cf4609c335911126734c341071d4943cba8 /llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp
parent303a7f7a26e2aae1cb85f49dccbc0b5d14e0b2e0 (diff)
downloadllvm-2fe0ea8261cf40d9c1ccdb9af633328290dd925e.zip
llvm-2fe0ea8261cf40d9c1ccdb9af633328290dd925e.tar.gz
llvm-2fe0ea8261cf40d9c1ccdb9af633328290dd925e.tar.bz2
DAG: Handle expanding strict_fsub into fneg and strict_fadd
The AMDGPU handling of f16 vectors is terrible still since it gets scalarized even when the vector operation is legal. The code is is essentially duplicated between the non-strict and strict case. Apparently no other expansions are currently trying to do this. This is mostly because I found the behavior of getStrictFPOperationAction to be confusing. In the ARM case, it would expand strict_fsub even though it shouldn't due to the later check. At that point, the logic required to check for legality was more complex than just duplicating the 2 instruction expansion.
Diffstat (limited to 'llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp')
0 files changed, 0 insertions, 0 deletions