Does anyone understand the purpose of : TargetRegisterInfo::getMinimalPhysRegClass ??? Why is there the presumption to use the minimal subclass? For Mips, it would work for me if we changed this to a virtual function and then I could override this to have it chose the proper register class based on the processor. I want to introduct a different register class for MIPS 16 but don't want it to chose MIPS 16 when I'm compiling for MIPS 32. We don't have any subclassing we are needing in MIPS, in the true sense of subclassing. Reed
On May 14, 2012, at 1:02 PM, reed kotler wrote:> Does anyone understand the purpose of : > > TargetRegisterInfo::getMinimalPhysRegClass ???Barely.> Why is there the presumption to use the minimal subclass?The function can be traced back to a time when men were men and registers belonged to ONE register class. That concept doesn't make sense any longer, as LLVM supports and aggressively uses overlapping register classes. I changed the meaning of the function to be 'the most specific register class containing Reg' which at least attempts to assign some meaning to a unique answer. In general, there isn't a good answer to "What is the register class of R?"> I want to introduct a different register class for MIPS 16 but don't > want it to chose MIPS 16 when > I'm compiling for MIPS 32.What exactly are you trying to do? The getMinimalPhysRegClass hook shouldn't be used for much these days. The most prominent client is PEI spilling callee-saved registers. The register allocator is generally assuming that sub-classes of legal register classes are usable. That is a pervasive assumption. /jakob
On May 14, 2012, at 1:02 PM, reed kotler wrote:> I want to introduct a different register class for MIPS 16 but don't > want it to chose MIPS 16 when > I'm compiling for MIPS 32.I bet your problem is here: if (RC == &Mips::CPURegsRegClass) Compare to: if (ARM::GPRRegClass.hasSubClassEq(RC)) { It is usually wrong to test register class equality. You almost always want hasSubClassEq() instead. /jakob
On 05/14/2012 02:17 PM, Jakob Stoklund Olesen wrote:> On May 14, 2012, at 1:02 PM, reed kotler wrote: > >> Does anyone understand the purpose of : >> >> TargetRegisterInfo::getMinimalPhysRegClass ??? > Barely. > >> Why is there the presumption to use the minimal subclass? > The function can be traced back to a time when men were men and registers belonged to ONE register class. That concept doesn't make sense any longer, as LLVM supports and aggressively uses overlapping register classes. > > I changed the meaning of the function to be 'the most specific register class containing Reg' which at least attempts to assign some meaning to a unique answer. > > In general, there isn't a good answer to "What is the register class of R?" > >> I want to introduct a different register class for MIPS 16 but don't >> want it to chose MIPS 16 when >> I'm compiling for MIPS 32. > What exactly are you trying to do? The getMinimalPhysRegClass hook shouldn't be used for much these days. The most prominent client is PEI spilling callee-saved registers. > > The register allocator is generally assuming that sub-classes of legal register classes are usable. That is a pervasive assumption. > > /jakob >I'm not using getMinimalPhysRegClass. Some target independent code is using it. It makes trouble for us and I would like to submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this method still exists. I want to add another register class for Mips16 and don't want to define a Mips16 set of registers because in reality there is no such thing; MIPS16 is an application extension that can exist for either Mips32 or Mips64 which uses a different instruction encoding. When I'm compiling for -mips23 -nomips16 I don't want the mips16 register class being passed to any functions which take such a register class parameter. As it is right now, it sees mips16 as the minimal size class and passes it when I'm compiling for -mips32 -nomips16