cmd/compile: prefer to cheaply re-materialize after call site instead of spilling #32255
Comments
Thanks for the suggestion. Unfortunately it does not look like it changes the example output. It seems that CL is specific to loops while this issue is generally only concerned with re-materialization after calls (does not even need to involve and if). Before I start digging deeper. Any hints where to best look for making the compiler prefer to materialize cheap ops (e.g. adds) with constants (I guess there is the additional constraint that the added too value is loadable from stack) after calls? |
The main levers for that are in tighten and in regalloc. Search for rematerializeable in regalloc, because regalloc does just what you want for rematerializeable values: recompute instead of spill. And as you can see from the CL I linked, tighten may also need to be made aware of regalloc’s policies so that they don’t work at cross purposes. Worth mentioning that I’m AFK and haven’t at exactly how ssa handles the code you’ve posted. (I am also reminded of https://go-review.googlesource.com/c/go/+/38448/, which it would be nice to resuscitate, but which is unrelated.) |
go tip
While working on changing runtime.growslice to not return the length of the new slice (like was done for runtime.makeslice 020a18c) I ran into the issue of not being able to make the compiler rematerialize the new slice length instead of spilling it in
go/src/cmd/compile/internal/gc/ssa.go
Line 2479 in d97bd5d
There generally seems to be a missed opportunity for the compiler to prefer recomputing a value that is cheap to compute from other values that too need to be loaded after a call.
Hand distilled example:
produces:
Neither
Or
avoids the spilling.
@josharian @randall77 @cherrymui
The text was updated successfully, but these errors were encountered: