diff options
| author | Volodymyr Vasylkun <vvmposeydon@gmail.com> | 2024-07-12 21:41:49 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-07-12 21:41:49 +0100 |
| commit | afb584a5622d67d19539d30287bc8af461f48ca8 (patch) | |
| tree | 599820b104123fe1cb9673070f4078d156f1203b /llvm/lib/CodeGen/TargetLoweringBase.cpp | |
| parent | bee240367cc48bbc93fe5eb57d537968dfe4419f (diff) | |
| download | llvm-afb584a5622d67d19539d30287bc8af461f48ca8.zip llvm-afb584a5622d67d19539d30287bc8af461f48ca8.tar.gz llvm-afb584a5622d67d19539d30287bc8af461f48ca8.tar.bz2 | |
[SelectionDAG] Ensure that we don't create `UCMP`/`SCMP` nodes with operands being scalars and result being a 1-element vector during scalarization (#98687)
This patch fixes a problem that existed before where in some situations
a `UCMP`/`SCMP` node which operated on 1-element vectors had a legal
result type (i.e. `v1i64` on AArch64), but illegal operands (i.e.
`v1i65`). This meant that operand scalarization was performed on the
node and the operands were changed to a legal scalar type, but the
result wasn't. This then led to `UCMP`/`SCMP` nodes with different
vector-ness of operands and result appearing in the SDAG. This patch
addresses this issue by fully scalarizing the `UCMP`/`SCMP` node and
then turning its result back into a 1-element vector using a
`SCALAR_TO_VECTOR` node.
It also adds several assertions to `SelectionDAG::getNode()` to avoid
this or a similar issue arising in the future. I wasn't sure if these
two changes are unrelated enough to warrant two small separate PRs, but
I'm happy to split this PR into two if that's deemed more appropriate.
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringBase.cpp')
0 files changed, 0 insertions, 0 deletions