Fixes a regression in v_mad_mixhi_f16_f16lo_f16lo_f16lo_undeflo_clamp_precvt.
Depends on D134354
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/lib/Target/AMDGPU/SIInstructions.td | ||
|---|---|---|
| 2740–2741 | Why does this pattern use SReg_32? That doesn't make any sense to me. | |
| llvm/lib/Target/AMDGPU/SIInstructions.td | ||
|---|---|---|
| 2740–2741 | The output should change to match. It makes sense for the old DAG select everything to scalar and hack up to vector later approach | |
| llvm/lib/Target/AMDGPU/SIInstructions.td | ||
|---|---|---|
| 2740–2741 | Well I still don't get why it ever made sense. I know we used to select SALU instructions by default, but this is a VALU instruction with an SGPR operand. I thought we always used VGPR operands by default for VALU instructions, to avoid having to think about constant bus restrictions until SIFoldOperands. | |
| llvm/lib/Target/AMDGPU/SIInstructions.td | ||
|---|---|---|
| 2740–2741 | The register class in the pattern used to mean less and was practically an alias for the type. There was a finalize ISel hook to fixup constant bus violations | |