search for: addrreg0

...re i64 %_tmp250, i64* %_tmp255 %_tmp256 = load i64** %cse6.103 %_tmp257 = load i64* %_tmp256 which means the same address is loaded twice, first to store a value, and then to load it back. The MachineInstructions to load an i64 are first pseudos and are then split post regalloc and become SU(0): addrReg0 = load *fp(-50) // Two address registers with same value SU(1): addrReg1 = load *fp(-50) SU(2): store dataReg0:lo, *addrReg0(2) // Store a register in two parts SU(3): store dataReg0:hi, *addrReg0 SU(4): dataReg1:lo = load *addrReg1(2) // Load a register in two parts SU(5): dataReg1:hi = load *ad...

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside

...iring rule defined for any such occurence. Possibly, one could add a Constraint per instruction 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 settin...

...s that the normal constraint model doesn't support. Constraints are modeled as matrices, so any specific 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...

...load i64** %cse6.103 > %_tmp257 = load i64* %_tmp256 > > which means the same address is loaded twice, first to store a value, and then to load it back. > > The MachineInstructions to load an i64 are first pseudos and are then > split post regalloc and become > > SU(0): addrReg0 = load *fp(-50) // Two address registers with same value > SU(1): addrReg1 = load *fp(-50) > SU(2): store dataReg0:lo, *addrReg0(2) // Store a register in two > parts > SU(3): store dataReg0:hi, *addrReg0 > SU(4): dataReg1:lo = load *addrReg1(2) // Load a register in two parts &gt...

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"