[llvm] [SystemZ] Eliminate call sequence instructions early. (PR #77812)

[Jonas Paulsson via llvm-commits]

JonPsson1 wrote:

I rebuilt everything, and to my surprise I now saw different numbers than before:

main/nfc patch <-> patch but erasing MI
```
Spill|Reload   :               608814               608692     -122
Copies         :              1021002              1020968      -34
```
So at this moment it looks like that small variation can go either way depending on the shape of the compiler on the given day.

I also ran spec. With all benchmarks, ("mini"):

```
Improvements "eraseMI":
0.981: i541.leela_r 
0.990: f538.imagick_r 
0.996: i525.x264_r 

Regressions "eraseMI":
1.013: i505.mcf_r 
1.011: i523.xalancbmk_r 
1.010: i520.omnetpp_r 
1.009: i502.gcc_r 
1.007: f544.nab_r 
1.006: i557.xz_r 

```
That looked like a slight general regression. However, I also ran a few select benchmarks in parallel with the "full" run:

```
Improvements "eraseMI":
0.987: i523.xalancbmk_r 
0.991: f544.nab_r 
0.996: i541.leela_r 

Regressions "eraseMI":
1.013: i520.omnetpp_r 
1.006: i505.mcf_r 
1.004: i531.deepsjeng_r 
1.002: i502.gcc_r 
1.001: i557.xz_r 
```
With these runs it was a general tie on those select benchmarks. 

Given that the spilling has varied a bit both ways, I don't see much point in looking at the MI scheduler. There is already a phys-reg heuristic there, so it should work well in general.

All the benchmarks have not been run fully, but it looks to me that it should be ok to simply remove the MIs and trust that the mi-scheduler will handle it without the scheduling barriers.
 

https://github.com/llvm/llvm-project/pull/77812