Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Removed extra BaseClassOrder assignments and use Reg16Types.types instead of [i16, f16].
llvm/lib/Target/AMDGPU/SIRegisterInfo.td | ||
---|---|---|
593–594 | Indeed these are now base classes to no registers. Nice catch, thanks. |
llvm/lib/Target/AMDGPU/SIRegisterInfo.td | ||
---|---|---|
1036 | Does this really work when you have an RC with registers of different size? |
llvm/lib/Target/AMDGPU/SIRegisterInfo.td | ||
---|---|---|
1036 |
It seems so, yes. Downstream I see us generating instructions like v_and_b16 v0.l, s2, v0.l without problem. |
LGTM
llvm/lib/Target/AMDGPU/SIRegisterInfo.td | ||
---|---|---|
1036 | OK, thanks! I used to have problems with this in the past, thus the question. |
llvm/lib/Target/AMDGPU/SIRegisterInfo.td | ||
---|---|---|
602 | I think the comment downstream about which instruction types use which types of Registers is helpful. | |
llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir | ||
31–33 | Unrelated to this patch, but I don't understand the purpose of these tests. It looks like we are referencing register classes by number in the test input. Therefore any time we modify the number of register classes the tests changes their meaning. |
llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir | ||
---|---|---|
31–33 | The raw number thing is a syntactical inconvenience from how inlineasm is represented. Ideally the mir printer/parser would produce something nicer. I think the purpose of the test is reasonably clear from the comment at the top |
llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir | ||
---|---|---|
31–33 | How can one determine if the change in output is still correct? The different RC choices in coalescer-early-clobber-subreg.mir are even more abstract. Is the RC to be ignored? |
llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir | ||
---|---|---|
31–33 | the printed class name should be correct, you just get the added bonus random number. Fur the purpose of this test the class doesn't really matter. However there are no 16-bit values in this test, so I don't understand how this ended up with any vgpr16 references in the first place |
llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir | ||
---|---|---|
31–33 | The InlineAsm instruction uses the numeric register class ids when computing these flags for register operands. These ids may change as we add or remove register classes. D78088 made the meaning of these flags visible in MIR tests, but there is still no support on the parser side for such operands. |
llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir | ||
---|---|---|
31–33 |
Exactly. |
Do VGPR_LO16 and VGPR_HI16 need to define BaseClassOrder? From the comments below it sounds like the base class of a 16-bit VGPR will always be VGPR_16_Lo128 or VGPR_16.