The register size determination will be implemented directly in TargetRegisterInfo, to support register classes with variable-sized registers. See D24631 for further discussion.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Target/AMDGPU/MCTargetDesc/SIMCCodeEmitter.cpp | ||
---|---|---|
217 | Space around / | |
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | ||
231–233 | I would prefer to add a new field in the register class than introducing more giant switches that need updates. Most of these register classes should be omitted also since only a handful are actually allocatable. VS_32RegClass for example is only used for operand constraints |
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | ||
---|---|---|
231–233 | Besides the unallocatable point, I guess this isn't so bad right now. I think we're going to need to do something different in these cases anyway to support 16-bit immediates in a 32-bit register class |
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | ||
---|---|---|
231–233 | Oh, this is looking directly at the operand class. In that case, you can remove all of the R600_* classes, VReg_1,and TTMP* |
Removed unnecessary register classes from the switch statement.
Applied other inline comments.
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | ||
---|---|---|
231–233 | Also removed SCC_CLASS. However I kept VS_32 and VS_64, even though they are not allocatable, because without VS_32 I had assertions in check-llvm. |
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | ||
---|---|---|
231–233 | So will this function be replaced with a TargetRegisterInfo query in the future? That's my impression from the description in the summary. |
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | ||
---|---|---|
231–233 | No. Unfortunately, there is no TargetRegisterInfo available at the places where this function is used. |
What do you think about this change, specifically, about moving the register size queries out of the MC layer?
Whether it's this patch or another one is not quite as important, but if we make a decision about that aspect, I will be able to move on with the implementation.
This is the context:
http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html
Space around /