search for: sreg_64

...from following the subreg indices into the wrong classes but it would also make it harder to define the register banks. > I'm a little confused about what the issue is. AMDGPU has 2 64-bit register classes each with sub0 and sub1 sub-registers: VReg_64:sub0=VGPR_32 VReg_64:sub1=VGPR_32 SReg_64:sub0=SGPR_32 SReg_64:sub1=SGPR_32 Are you saying that tablegen considers VReg_64:sub0 and SReg_64:sub0 to be the same sub-register class because they are both called sub0 ? -Tom >> On 10 May 2017, at 21:58, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at...

Hi Tom, The output: Added VReg_64(explicit) Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64) is saying that VS_32 was added because VReg_64 was explicitly specified and that while inspecting VS_32, it noticed that every register in VS_32 was a subregister of a register from VReg_64 using a single common subregister index. I've added some more tracing to my local copy and

Hi, On my target, most value types can be stored in two register classes. For example: def SReg_64 : RegisterClass<"AMDGPU", [i64], 64, (add SGPR_64, VCC, EXEC)>; def VReg_64 : RegisterClass<"AMDGPU", [i64], 64, (add VGPR_64)>; What criteria should I use to decide which register class to associate with each type using TargetLowering::addRegisterClass() ? Thanks,...