Open Quuxplusone opened 6 years ago
Attached spill.c
(338 bytes, text/x-csrc): input program
The reason the output looks so strange is that we decided to spill before post-ra scheduling. Try "-mllvm -disable-post-ra".
Good catch. That generates code like this:
...
vmov.f64 d13, #4.000000e+00
vmov.f64 d14, #1.000000e+01
vmov.f64 d15, #8.000000e+00
vmov.f64 d6, #6.000000e+00
vmla.f64 d9, d8, d11
vsub.f64 d5, d12, d5
vmov.f64 d8, #1.000000e+00
vmul.f64 d10, d10, d13
vadd.f64 d11, d1, d14
vadd.f64 d12, d2, d15
...
in which the live ranges for d6 and d13-d15 all overlap. Looks like the pre-RA
scheduler doesn't try to minimize register pressure, at least not very hard. I
can indeed make the spill go away with "-mllvm -pre-RA-sched=list-burr".
IMHO the default scheduler for this platform, whatever it is, is badly chosen.
Yes, the ARM backend unfortunately has not been migrated to the newer MachineScheduler yet. With the MachineScheduler enabled for ARM, there are no spills in the example.
spill.c
(338 bytes, text/x-csrc)