[LLVMdev] problem trying to write an LLVM register-allocation pass

[Susan Horwitz]

Thanks Lang, I'll try substPhysReg.

I did try your latest code, and although it made the assembler errors go 
away, now some of my tests produce bad output when executed.  I need to 
look into that some more...  (I did change my "usedPregSet" to be ALL 
pregs used in the whole function, not just those in the current 
instruction, so the problem should not be the erroneous over-writing of 
a live preg.)

Also, I'm confused about the code that gets a preg for a given vreg. 
Previously,you gave me code that takes into account the "allocation 
order" and the "reserved regs", including the following:
	 BitVector reservedRegs = TRI->getReservedRegs(Fn);
          ArrayRef<uint16_t> rawOrder = trc->getRawAllocationOrder(Fn);
          ArrayRef<uint16_t>::iterator rItr = rawOrder.begin();
          while (rItr != rawOrder.end()) {
           while (rItr != rawOrder.end() && reservedRegs.test(*rItr)) {
             ++rItr;
           }

As I recall, this prevented some failed assertion.  Why has that code 
gone away?

Susan


On 11/15/2012 01:45 PM, Lang Hames wrote:
> Hi Susan,
>
> Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg,
> const TargetRegisterInfo& TRI)'. That substitutes the given physreg for
> a virtreg operand, taking the subregister index into account. That is
> what my examples have been doing manually. Using substPhysReg would
> allow you to tidy the Gcra code up slightly.
>
> - Lang.
>
>
> On Thu, Nov 15, 2012 at 11:21 AM, Lang Hames <lhames at gmail.com
> <mailto:lhames at gmail.com>> wrote:
>
>     Thanks Jakob. I should have mentioned that earlier. :)
>
>     When you see mismatched sizes on operands it's a fair bet that the
>     subreg rewriting has gone wrong. I should have pulled that entirely
>     out of the preg search loop in the previous example.
>
>     Fixed version attached.
>
>     - Lang.
>
>