[LLVMdev] Spilling predicate registers

Jakob Stoklund Olesen stoklund at 2pi.dk
Fri Dec 9 14:26:37 PST 2011


On Dec 9, 2011, at 2:03 PM, Arnold Schwaighofer wrote:

>> I am not sure extending the scavenger is the right way to go about this.
>> 
>> There are two different situations where we might need extra registers to
>> spill something:
>> 
>> 1. When spilling a weird register class like predicate registers, we
>> already known during register allocation that we will need a scratch GPR
>> to assist with the spill.
>> 
>> 2. When spilling to a stack slot that may be out of reach of the offset
>> encoding.
>> 
>> The scavenger is really meant to handle the second case, although there is
>> nothing wrong with using it for the first case as well.
>> 
>> However, in the first case we know immediately that a scratch register is
>> necessary, so why not just ask the register allocator for one?  Basically,
>> I think storeRegToStackSlot should be allowed to call
>> MRI->createVirtualRegister() when it needs a scratch register.
> 
> That was an alternative I was looking at (extending the scavenger seemed
> the quicker fix). The greedy allocator would just add the new live range
> to the queue?

More or less. Handling this in LiveRangeEdit would give you basic, greedy, and pbqp in one go. It would need to:

- Notice that a new virtual register has been created.
- Compute the live range from scratch.
- Add the live range to the queue.

These allocators already understand that spilling can create new live ranges, and LRE keeps track of them. This could actually simplify the spiller as well, since it wouldn't have to manually compute live ranges.

LiveRangeCalc::calculate() can compute a live range from scratch. This function just needs to be implemented.

> I have not looked at the implications for fast.

Thinking about it, I don't think this will be easy, perhaps not worthwhile.

When compiling at -O0, you can just reserve an extra register. There won't be significant register pressure anyway.

/jakob




More information about the llvm-dev mailing list