Open afonso360 opened 1 year ago
I couldn't fit this in the initial issue due to a character limit.
Tested locally with the latest regalloc2 (7d90ca9) and it still produces the same output.
@cfallin and I looked through this, and it looks like the problem is the current splitting heuristic in RA2: it's splitting at the location of the first conflict, which happens to be that first load, rather than at the point where a fixed constraint exists (the return instruction). Splitting early means that we get an allocation of a3 somewhat arbitrarily to v1, however the other half of the split which contains the second load and the return now also conflicts with the ultimate requirement for v1 to be in a0, thus a second split is introduced after the second load. That second split introduces the allocation of v1 to a4, which is why we see the move from a3 to a4 between the first two loads, and ultimately the move from a4 to a0 to satisfy the abi.
One possible solution here would be to augment the split point heuristic to look at the region after the conflict and move the split point to right before the first fixed use, which would in cases like this ensure that we weren't setting ourselves up for additional splits that would require additional moves.
👋 Hey,
This is something that I noticed while working on #7123.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above
Expected Results
We could eliminate the first move by generating something along these lines:
Actual Results
We get an extra move between loads.
Versions and Environment
Cranelift version or commit: main
Operating system: Linux
Architecture: RISC-V
Extra Info
VCode: