search for: offsreg2

...on def as well to indicate the use of the register pairing rule, and to allow instances where it does not apply. PBQP extension (suggestion) ====================== Tablegen: def regPair : registerPair<AddrReg0, OffsReg0>, ~or~ def regPair: registerPairing<AddrReg0, [OffsReg0, OffsReg1, OffsReg2]>; ~or~ ?? in the instruction such as a load: ld dst, addrReg, offsReg then PBQP must follow the rule and only allocate legal combinations of addrReg and offsReg. I beleive this should work by setting the cost to infinity for illegal combinations. I supervised a bacheolor student here last y...

...cific type of constraint wouldn't be mentioned in the source file. > PBQP extension (suggestion) > ====================== > > Tablegen: > > def regPair : registerPair<AddrReg0, OffsReg0>, > ~or~ > def regPair: registerPairing<AddrReg0, [OffsReg0, OffsReg1, OffsReg2]>; > ~or~ > ?? I am not sure how much easier that would be than the current approach. I'll leave that up to Lang. > I beleive this should work by setting the cost to infinity for illegal combinations. I supervised a bacheolor student here last year (Jakob Stengård), and as far as...

On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Spill-free register allocation sounds great, why not do it for all register classes? > , and a register allocator would have to implement register pairing.

Hi, My target has special requirements during register allocation - there is both a need to handle register pairing and to never spill a flag result reg-class (which might happen at -O0 for no obvious reason). Since neither of these issues seems to be supported, I have tried to pre-allocate these registers in the preRA pass. This has resulted in "using undefined physical register"