This mostly benefits AMDGPU where arguments to IMAGE instructions are
sometimes packed into the two 16-bit halves of a 32-bit register.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-build-vector-trunc.v2s16.mir | ||
---|---|---|
157 ↗ | (On Diff #380646) | I could just remove all these "undef" test cases, since there is no longer any code in AMDGPUInstructionSelector that handles IMPLICIT_DEF specially. |
Should add some MIR tests specifically for this in case we decide to stop using G_BUILD_VECTOR_TRUNC someday
llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp | ||
---|---|---|
630–637 ↗ | (On Diff #380646) | I think deleting this should be split into a separate patch |
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-build-vector-trunc.v2s16.mir | ||
157 ↗ | (On Diff #380646) | Yes |
llvm/test/CodeGen/AMDGPU/GlobalISel/clamp-minmax-const-combine.ll | ||
---|---|---|
62–67 | What happened here? |
llvm/test/CodeGen/AMDGPU/GlobalISel/clamp-minmax-const-combine.ll | ||
---|---|---|
62 | Regression here for the same reasons as in combine-fcanonicalize.mir. | |
llvm/test/CodeGen/AMDGPU/GlobalISel/combine-fcanonicalize.mir | ||
256 | Regression here because combining G_BUILD_VECTOR_TRUNC %zero_s32(s32), %undef(s32) into a G_BITCAST breaks detection of a constant splat with some elements undef. Any thoughts on how to fix this? Perhaps it was not a good idea to do this as a combine after all, despite the comment in AMDGPUInstructionSelector::selectG_BUILD_VECTOR_TRUNC? |
llvm/test/CodeGen/AMDGPU/GlobalISel/combine-fcanonicalize.mir | ||
---|---|---|
256 | I think the globalisel version of isCanonicalized needs to be implemented for G_BITCAST |
llvm/test/CodeGen/AMDGPU/GlobalISel/combine-fcanonicalize.mir | ||
---|---|---|
256 | Or everything really. It's pretty thin right now |
llvm/test/CodeGen/AMDGPU/GlobalISel/combine-fcanonicalize.mir | ||
---|---|---|
256 | I'm not sure having isCanonicalized look through a bitcast from s32 to <2 x s16> is a great idea. And it wouldn't help with the regression in clamp-minmax-const-combine.ll which is to do with recognizing vector splat constants where some elements may be undef. I see the DAG version of isCanonicalized looks through ISD::BITCAST, but I don't see how that can be safe when it loses the information about whether you were looking at (say) an f32 or a vector of f16s. |
Regression here for the same reasons as in combine-fcanonicalize.mir.