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

[Lang Hames]

Hi Susan,

It looks like the allocation-order aware code didn't make it into your
email on November 7th, and I didn't think to add it back in. This code is
important, and its omission could be the cause of the errors your seeing.

- Lang.


On Thu, Nov 15, 2012 at 12:09 PM, Susan Horwitz <horwitz at cs.wisc.edu> wrote:

> 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.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/ee568dd3/attachment.html>