[LLVMdev] Adding a new ARM RegisterClass

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue Jun 25 09:34:00 PDT 2013


On Jun 25, 2013, at 7:10 AM, Daniel Stewart <stewartd at codeaurora.org> wrote:

> If I add a new RegisterClass however, the dynamically created GPRPair class corresponding to this new RegisterClass overlaps with the dynamically created class for rGPR. In Thumb2InstrInfo.cpp, the dynamically created TargetRegisterClass GPRPair_with_gsub_1_in_rGPRRegClass is explicitly called out. If I add my new class, the class GPRPair_with_gsub_1_in_rGPRRegClass is never created, instead the class GPRPair_with_gsub_1_in_newGPRRegClass is created. Compilation therefore fails. I could simply rename the RegisterClass so that it is alphabetically sorted after rGPR, but that seems to simply be avoiding the real issue.
>  
> Should explicit references to dynamically generated classes be done? 

In my opinion, no. If source code needs to refer to a register class by name, that class should be defined explicitly in the .td files.

The present case is easy, though:

  if (ARM::GPRPairRegClass.hasSubClassEq(RC)) {
    // Thumb2 STRD expects its dest-registers to be in rGPR. Not a problem for
    // gsub_0, but needs an extra constraint for gsub_1 (which could be sp
    // otherwise).
    MachineRegisterInfo *MRI = &MF.getRegInfo();
    MRI->constrainRegClass(SrcReg, &ARM::GPRPair_with_gsub_1_in_rGPRRegClass);

The function TRI->getMatchingSuperRegClass(RC, ARM::rGPR, ARM::gsub1) provides the right register class whether it is named or synthetic.

Alternatively, we could add API: MRI->constrainRegClassForSubReg(SrcReg, ARM::rGPR, ARM::gsub1).

But defining an rGPRPair register class as Tim suggested would also work.

/jakob




More information about the llvm-dev mailing list