[LLVMdev] Live range splitting with Ising models
Jakob Stoklund Olesen
stoklund at 2pi.dk
Thu Aug 8 08:55:12 PDT 2013
On Aug 8, 2013, at 8:24 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> On 7 August 2013 17:06, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> With the D-Wave computer in the news recently, you may find it interesting that LLVM’s register allocator is using Ising models to compute regions for live range splitting.
>>
>> The problem of finding a region for splitting a live range is mapped to an Ising model with the help of the edge bundle graph, see EdgeBundles.h. A node in the edge bundle graph represents a set of CFG edges that enter or leave the same basic block, see also ‘llc -view-edge-bundles’.
>>
>> A region for splitting a live range can be described as a coloring of the edge bundle graph, such that ‘spin up’ means that the live range should go in a register through this bundle, and ‘spin down’ means that the live range should go on the stack. The connections between edge bundle nodes correspond to basic blocks, and we give each connection a weight that is the expected execution frequency of the corresponding basic block. This means that the ‘energy’ of a solution is the same as the total expected execution frequency of the spill code required to implement the live range split. The optimal split region is the ‘ground state’ of the Ising model.
>
> Thanks for the information. Is this done iteratively? I.E., we solve a
> ising model every time we cannot assign a register to a range and want
> to decide if we should split one of the already assigned ranges?
Not quite. If no register can be found for a live range, we first try to evict an already assigned live range with a smaller spill weight. If none is found, we move on to splitting the live range.
It can happen that a split range gets evicted by a third range with higher spill weight. In that case, the range is split again, and this process can iterate as long as the splitting is making progress. IIRC, 'progress' is defined as reducing the number of basic blocks covered by the live range.
Thanks,
/jakob
More information about the llvm-dev
mailing list