Skip to content

Commit 33ac6cb

Browse files
committed
Heuristic improvement: reg-scan offset by inst location.
We currently use a heuristic that our scan for an available PReg starts at an index into the register list that rotates with the bundle index. This is a simple way to distribute contention across the whole register file more evenly and avoid repeating less-likely-to-succeed reg-map probes to lower-numbered registers for every bundle. After some experimentation with different options (queue that dynamically puts registers at end after allocating, various ways of mixing/hashing indices, etc.), adding the *instruction offset* (of the start of the first range in the bundle) as well gave the best results. This is very simple and gives us a likely better-than-random conflict avoidance because ranges tend to be local, so rotating through registers as we scan down the list of instructions seems like a very natural strategy. On the tests used by our `cargo bench` benchmark, this reduces regfile probes for the largest (459 instruction) benchmark from 1538 to 829, i.e., approximately by half, and results in an 11% allocation speedup.
1 parent 8e923b0 commit 33ac6cb

File tree

2 files changed

+20
-15
lines changed

2 files changed

+20
-15
lines changed

README.md

+7-13
Original file line numberDiff line numberDiff line change
@@ -111,27 +111,21 @@ benches/0 time: [365.68 us 367.36 us 369.04 us]
111111
```
112112

113113
I then measured three different fuzztest-SSA-generator test cases in
114-
this allocator, `regalloc2`, measuring between 1.05M and 2.3M
114+
this allocator, `regalloc2`, measuring between 1.1M and 2.3M
115115
instructions per second (closer to the former for larger functions):
116116

117117
```plain
118118
==== 459 instructions
119-
benches/0 time: [424.46 us 425.65 us 426.59 us]
120-
thrpt: [1.0760 Melem/s 1.0784 Melem/s 1.0814 Melem/s]
119+
benches/0 time: [377.91 us 378.09 us 378.27 us]
120+
thrpt: [1.2134 Melem/s 1.2140 Melem/s 1.2146 Melem/s]
121121
122122
==== 225 instructions
123-
benches/1 time: [213.05 us 213.28 us 213.54 us]
124-
thrpt: [1.0537 Melem/s 1.0549 Melem/s 1.0561 Melem/s]
123+
benches/1 time: [202.03 us 202.14 us 202.27 us]
124+
thrpt: [1.1124 Melem/s 1.1131 Melem/s 1.1137 Melem/s]
125125
126-
Found 1 outliers among 100 measurements (1.00%)
127-
1 (1.00%) high mild
128126
==== 21 instructions
129-
benches/2 time: [9.0495 us 9.0571 us 9.0641 us]
130-
thrpt: [2.3168 Melem/s 2.3186 Melem/s 2.3206 Melem/s]
131-
132-
Found 4 outliers among 100 measurements (4.00%)
133-
2 (2.00%) high mild
134-
2 (2.00%) high severe
127+
benches/2 time: [9.5605 us 9.5655 us 9.5702 us]
128+
thrpt: [2.1943 Melem/s 2.1954 Melem/s 2.1965 Melem/s]
135129
```
136130

137131
Though not apples-to-apples (SSA vs. non-SSA, completely different

src/ion/mod.rs

+13-2
Original file line numberDiff line numberDiff line change
@@ -2570,6 +2570,17 @@ impl<'a, F: Function> Env<'a, F> {
25702570
} else {
25712571
n_regs
25722572
};
2573+
// Heuristic: start the scan for an available
2574+
// register at an offset influenced both by our
2575+
// location in the code and by the bundle we're
2576+
// considering. This has the effect of spreading
2577+
// demand more evenly across registers.
2578+
let scan_offset = self.ranges[self.bundles[bundle.index()].first_range.index()]
2579+
.range
2580+
.from
2581+
.inst
2582+
.index()
2583+
+ bundle.index();
25732584
for i in 0..loop_count {
25742585
// The order in which we try registers is somewhat complex:
25752586
// - First, if there is a hint, we try that.
@@ -2587,15 +2598,15 @@ impl<'a, F: Function> Env<'a, F> {
25872598
(0, Some(hint_reg)) => hint_reg,
25882599
(i, Some(hint_reg)) => {
25892600
let reg = self.env.regs_by_class[class as u8 as usize]
2590-
[(i - 1 + bundle.index()) % n_regs];
2601+
[(i - 1 + scan_offset) % n_regs];
25912602
if reg == hint_reg {
25922603
continue;
25932604
}
25942605
reg
25952606
}
25962607
(i, None) => {
25972608
self.env.regs_by_class[class as u8 as usize]
2598-
[(i + bundle.index()) % n_regs]
2609+
[(i + scan_offset) % n_regs]
25992610
}
26002611
};
26012612

0 commit comments

Comments
 (0)