Yes, it looks like the scheduler is too aggressive moving loads earlier. Too many early loads means it has to immediately spill the loads, then restore them.

@jeremyfaller can you outline the exact steps you took to generate the ssa.html file? Thanks :)

It's env variable. You give it the name of the function you want the SSA for:

https://dave.cheney.net/2020/06/19/how-to-dump-the-gossafunc-graph-for-a-method

So for this instance, I think it was GOSSAFUNC=$FUNC go tool compile XXX.go.

When I filed this, I did some looking at this, it looked relatively simple to me. This is from memory, and likely to be wrong, but I think there's a heap in the schedule pass that just needs different priorities for the load/stores. (Or the heap isn't there, and that's what I was going to add.) From there it was just expanding the testing, etc. Seemed like a pretty simple fix.

Yeah, looking at src/cmd/compile/internal/ssa/schedule.go there's a heap. I think I thought it was as simple as turning that ValHeap into using float32 for scores, and just encoding the linenumber in decimal points just gently encourage "earlier in the code" to "earlier to schedule." It probably wasn't the best fix, but it would start the discussion, anyway.

My original proposal of using the souce line number will not work. And actually, it's already implemented in the heap in the schedule pass.

I did a little bit of digging into this issue over the holidays, and it looks slightly more complicated than I originally laid out. The SSA load instructions have dependencies between them, so sequential loads are all marked as dependent on one another. As such, the scheduler has a hard time moving them around. When I get spare cycles, I'll likely take a further look at this.

This is fixed at tip, probably from the new scheduler (CL 270940) plus CL 509856.