Allocation results in unnecessary moves around destructive operations

Start with the three cases in the regalloc2-repro repository, then compare their output with the reported fib.asm and fib.vcode files from the linked botlish audit. Trace the allocation around the destructive operations and verify that the unnecessary moves into r13 are reduced without regressing the repro cases.

I am implementing a Cranelift-based compiler stack for a new programming language where one design objective is efficient machine code. This is why early in development I am doing audits on the generated code to find out which inefficiencies are caused by the mid-end, which by the backend and which by missing language features.

In the asm dump of my fibonacci benchmark I saw this:

 177:	mov    rsi,r13
 17a:	mov    r14,rax
 17d:	sub    rsi,0x2
 181:	mov    r13,rsi
 184:	shl    rsi,1
 187:	mov    r13,rsi
 18a:	or     rsi,0x1
 18e:	mov    r13,rsi
 191:	mov    QWORD PTR [rbx+0x8],rsi

rsi is moved repeatedly into r13 for no discernible reason, then the content of rsi is moved into memory. r13 is later overwritten. So r13 was completely useless here.

The entire ASM is available in https://github.com/mwagner-webdev/botlish/blob/9cb689a/audit/native-scalar-asm/bench/fib.asm

This code was generated via Cranelift from this CLIF: https://github.com/mwagner-webdev/botlish/blob/9cb689a/audit/native-scalar-asm/bench/fib.vcode

I have a minimal repro here with three cases that illustrate the issue: https://github.com/mwagner-webdev/regalloc2-repro

I have zero experience with the workings of register allocators and it's all pretty fascinating. Obviously perfect allocation is impossible, but this looks like a clear-cut pathological case for which some heuristic may be found.