[LLVMdev] Adding a new ARM RegisterClass

[Daniel Stewart]

I'm looking at an issue where we want a particular pseudo-instruction to
choose from a set of registers that is not included in the existing set of
RegisterClass definitions. More concretely, there is a RegisterClass in
ARMRegisterInfo.td defined as

 

def rGPR : RegisterClass<"ARM", [i32], 32, (sub GPR, SP, PC)> {

  let AltOrders = [(add LR, rGPR), (trunc rGPR, 8)];

  let AltOrderSelect = [{

      return 1 + MF.getTarget().getSubtarget<ARMSubtarget>().isThumb1Only();

  }];

}

 

However, I'd like the instruction NOT to use the LR. I don't see an existing
RegisterClass defined with R0_R12;  something like:

 

def newGPR : RegisterClass<"ARM", [i32], 32, (add (sequence "R%u", 0, 12))>;

 

I can add this new RegisterClass myself and then modify the
pseudo-instruction definition to simply use my new RegisterClass. However,
TableGen creates a set of dynamically created classes for GPRPairs that hold
all the various incarnations of GPRPair sets that correspond to various
RegisterClass definitions (like GPR pairs just for R0-R7, another for rGPR
that doesn't contain the SP, .). 

 

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.

 

So, since I'm fairly new to LLVM, my question is, am I approaching this
correctly? Is adding a new RegisterClass something that is highly
discouraged? Is it better to force certain instructions to avoid certain
registers in the register allocation process? Should explicit references to
dynamically generated classes be done? 

 

Thanks,

Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130625/3cbb43de/attachment.html>