| commit | 0ca46a1757cdb3dd3b38bef077b45171a2dc3592 | |
| author | Eli Friedman <efriedma@quicinc.com> | |
| Thu, 8 Jul 2021 23:14:33 +0000 (8 16:14 -0700) | ||
| committer | Eli Friedman <efriedma@quicinc.com> | |
| Wed, 21 Jul 2021 17:58:40 +0000 (21 10:58 -0700) | ||
| tree | 41cafe588186644e47dd0240c88b9975311e4bdb | treesnapshot (tar.gz zip) |
| parent | f984ac2715f71c38a7872fa2c2ad535b3d4fa285 | commitdiff |
[SelectionDAG] Fix the representation of ISD::STEP_VECTOR.
The existing rule about the operand type is strange. Instead, just say
the operand is a TargetConstant with the right width. (Legalization
ignores TargetConstants, so it doesn't matter if that width is legal.)
Highlights:
1. I had to substantially rewrite the AArch64 isel patterns to expect a
TargetConstant. Nothing too exotic, but maybe a little hairy. Maybe
worth considering a target-specific node with some dagcombines instead
of this complicated nest of isel patterns.
2. Our behavior on RV32 for vectors of i64 has changed slightly. In
particular, we correctly preserve the width of the arithmetic through
legalization. This changes the DAG a bit. Maybe room for
improvement here.
3. I explicitly defined the behavior around overflow. This is necessary
to make the DAGCombine transforms legal, and I don't think it causes any
practical issues.
Differential Revision: https://reviews.llvm.org/D105673
The existing rule about the operand type is strange. Instead, just say
the operand is a TargetConstant with the right width. (Legalization
ignores TargetConstants, so it doesn't matter if that width is legal.)
Highlights:
1. I had to substantially rewrite the AArch64 isel patterns to expect a
TargetConstant. Nothing too exotic, but maybe a little hairy. Maybe
worth considering a target-specific node with some dagcombines instead
of this complicated nest of isel patterns.
2. Our behavior on RV32 for vectors of i64 has changed slightly. In
particular, we correctly preserve the width of the arithmetic through
legalization. This changes the DAG a bit. Maybe room for
improvement here.
3. I explicitly defined the behavior around overflow. This is necessary
to make the DAGCombine transforms legal, and I don't think it causes any
practical issues.
Differential Revision: https://reviews.llvm.org/D105673