[llvm-dev] TargetRegisterInfo::getCommonSubClass bug, perhaps.

[Quentin Colombet via llvm-dev]

> On Aug 26, 2019, at 7:36 PM, Nancy via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> ABCRegister.td :
> def SGPR32 : RegisterClass<"ABC", [i32], 16, (add
>    S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11,
>    S12, S13, S14, S15
>  )>;
> 
> def SFGPR32 : RegisterClass<"ABC", [f32], 16, (add
>    S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11,
>    S12, S13, S14, S15
>  )>;
> 
> ===== Instruction selection ends:
> ...
>            t8: i32 = ADDrr t37, t32
> ...
> Instruction Selection correct : i32 = ADDrr i32, i32
> 
> *** MachineFunction at end of ISel ***
> # Machine code for function _Z11scalar_loopPsS_ss: IsSSA, TracksLiveness
> ...
>  %31:sfgpr32 = ADDrr killed %32:sgpr32, %27:sgpr32
> ...
> 
> Here should not select f32 sfgpr32 register, debugger point to
> TargetRegisterInfo:: getCommonSubClass(const TargetRegisterClass *A,
>                    const TargetRegisterClass *B,
>                    const MVT::SimpleValueType SVT =
>                    MVT::SimpleValueType::Any)
> This function has been called 10+ in LLVM, only one place give
> specific SVT parameter. Most of those places are hard to get the
> MVT::SimpleValueType infos and use the default value. That's why
> sfgpr32 comes out. LLVM defect?

That doesn’t sound problematic. getCommonSubClass should have enough information to get the right register class from A and B.
What is your description of ADDrr. It sounds to me that you allowed ADDrr destination to use SFGPR32 and that would be your problem.

Cheers,
-Quentin

> 
> 
> -
> Best Regards,
> Yu Rong Tan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev