Detected on targets older then gfx10 (e.g. gfx9) for constants that are
too large to be inlined (constant are sgpr by default).
In med3 combine it is expected that regbankselect maps all operands of
min/max we try to match to vgpr. However constants are mapped to sgpr
and there will be a sgpr-to-vgpr copy. Matchers look through sgpr-to-vgpr
copies and return sgpr and these break constant bus restriction.
Build med3 with all vgpr operands. Use existing sgpr-to-vgpr copies for
matched sgprs. If there is no such copy (not expected) build one.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AMDGPU/AMDGPURegBankCombiner.cpp | ||
---|---|---|
155–157 | The subtarget should probably be cached in the combiner helper | |
156 | My intention was globalisel should not need to think about the constant bus restriction at all because it will be quickly become unmanageable. All code would need to be exactly aware of how the instructions will be selected, which is impossible. All VALU instructions should use all VGPR (or VCC) mappings | |
167 | Should not consider individual mappings, everything just needs to be VGPR | |
168–171 | Probably should have a constrain or copy to VGPR helper |
llvm/test/CodeGen/AMDGPU/GlobalISel/regbankcombiner-smed3.mir | ||
---|---|---|
16–26 | What is the difference between GFX9 and GFX10 here? Can they use a common prefix? |
llvm/lib/Target/AMDGPU/AMDGPURegBankCombiner.cpp | ||
---|---|---|
77–82 | This feels like more papering over unhandled constant regbankselect |
This feels like more papering over unhandled constant regbankselect