[llvm-commits] [llvm] r112742 - /llvm/trunk/lib/CodeGen/RegAllocPBQP.cpp

[Jim Grosbach]

Hi Evan,

Jakob and I talked about this prior to this set of changes beforehand to make sure we were on the same page regarding overall direction and philosophy for how the allocators should handle allocation orders. The idea of these patches is to better encapsulate functionality, simplify the implementation and improve robustness. These patches are a beginning step. I have some additional thoughts on how to further improve these interfaces, and I know Jakob does too. 

1. Conceptually, a register allocator should not allocate a reserved register. To do so is, by definition, incorrect. The less the allocators have to rely on the targets enforcing things like that, the more robust they are. In this case, a reserved register being in the allocation order is simply ignored when allocating.

2. Previously, targets had to maintain the information for reserved registers in multiple places. At minimum, in the isReservedReg() function and in any allocation orders for register classes containing those registers. With these changes, that's reduced to just the isReservedReg() function. The allocators automatically do the rest.

3. This allows targets to define their register classes more simply, without having to deal with all the conditional logic for when certain registers are reserved. Any conditionally reserved registers (based on qualities of the function being compiled) would require quite a bit of logic and code duplication in the begin/end iterators. That's no longer nearly so much the case. The ARM register class simplifications that followed are an example of this.

-Jim

The set of reserved registers isn't fixed, and having to update the allocation order iterators 
On Sep 9, 2010, at 11:53 PM, Evan Cheng wrote:

> Hmm. I really am not seeing the advantage of doing the check in every register allocator (as opposed to have allocation_order_* excluding non-allocatable registers). Now all the out-of-tree register allocators will need have the same code. I missed a lot of patches during the last few weeks. What's the motivation for this change?
> 
> Evan
> 
> On Sep 1, 2010, at 2:23 PM, Jim Grosbach wrote:
> 
>> Author: grosbach
>> Date: Wed Sep  1 16:23:03 2010
>> New Revision: 112742
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=112742&view=rev
>> Log:
>> The register allocator shouldn't consider allocating reserved registers. PBQP version.
>> 
>> Modified:
>>   llvm/trunk/lib/CodeGen/RegAllocPBQP.cpp
>> 
>> Modified: llvm/trunk/lib/CodeGen/RegAllocPBQP.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/RegAllocPBQP.cpp?rev=112742&r1=112741&r2=112742&view=diff
>> ==============================================================================
>> --- llvm/trunk/lib/CodeGen/RegAllocPBQP.cpp (original)
>> +++ llvm/trunk/lib/CodeGen/RegAllocPBQP.cpp Wed Sep  1 16:23:03 2010
>> @@ -587,6 +587,8 @@
>>  // Resize allowedSets container appropriately.
>>  allowedSets.resize(vregIntervalsToAlloc.size());
>> 
>> +  BitVector ReservedRegs = tri->getReservedRegs(*mf);
>> +
>>  // Iterate over virtual register intervals to compute allowed sets...
>>  for (unsigned node = 0; node < node2LI.size(); ++node) {
>> 
>> @@ -595,8 +597,12 @@
>>    const TargetRegisterClass *liRC = mri->getRegClass(li->reg);
>> 
>>    // Start by assuming all allocable registers in the class are allowed...
>> -    RegVector liAllowed(liRC->allocation_order_begin(*mf),
>> -                        liRC->allocation_order_end(*mf));
>> +    RegVector liAllowed;
>> +    TargetRegisterClass::iterator aob = liRC->allocation_order_begin(*mf);
>> +    TargetRegisterClass::iterator aoe = liRC->allocation_order_end(*mf);
>> +    for (TargetRegisterClass::iterator it = aob; it != aoe; ++it)
>> +      if (!ReservedRegs.test(*it))
>> +        liAllowed.push_back(*it);
>> 
>>    // Eliminate the physical registers which overlap with this range, along
>>    // with all their aliases.
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>