aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-readobj/llvm-readobj.cpp
diff options
context:
space:
mode:
authorRoman Lebedev <lebedev.ri@gmail.com>2022-10-24 20:11:19 +0300
committerRoman Lebedev <lebedev.ri@gmail.com>2022-10-24 20:27:02 +0300
commit377f27be87f92e82902be277bb02c401475c9aa1 (patch)
tree1a108e60ad366ae7aeb103592a0aef6c70e23764 /llvm/tools/llvm-readobj/llvm-readobj.cpp
parent52930162870fee52d0d9c07c5d66e5dce32b08e8 (diff)
downloadllvm-377f27be87f92e82902be277bb02c401475c9aa1.zip
llvm-377f27be87f92e82902be277bb02c401475c9aa1.tar.gz
llvm-377f27be87f92e82902be277bb02c401475c9aa1.tar.bz2
[X86] `DAGTypeLegalizer::ModifyToType()`: when widening w/ zeros, insert into undef and `and`-mask the padding away
We can expect that the sequence of inserting-of-extracts-into-undef will be successfully lowered back into widening of the source vector, but it seems that at least for X86 mask vectors, we have a really hard time recovering from inserting-into-zero. I've looked into alternative fix injection points, and they are much more involved, by the time of `LowerBUILD_VECTORvXi1()`/`LowerINSERT_VECTOR_ELT()` the constants might be obscured, so it does not seem like we can easily deal with this by lowering into bit math later on, some other pieces are missing. Instead, it seems like just clearing the padding away via an `AND`-mask is at least not a worse choice. Why create a problem where there wasn't one. Though yes, it is possible that there are cases where constants originate from the source IR, so some other fix may still be needed. Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D136046
Diffstat (limited to 'llvm/tools/llvm-readobj/llvm-readobj.cpp')
0 files changed, 0 insertions, 0 deletions