diff options
author | Matt Arsenault <Matthew.Arsenault@amd.com> | 2020-05-27 09:36:42 -0400 |
---|---|---|
committer | Matt Arsenault <arsenm2@gmail.com> | 2020-07-21 16:17:10 -0400 |
commit | 2fe0ea8261cf40d9c1ccdb9af633328290dd925e (patch) | |
tree | 77955cf4609c335911126734c341071d4943cba8 /llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp | |
parent | 303a7f7a26e2aae1cb85f49dccbc0b5d14e0b2e0 (diff) | |
download | llvm-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