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
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.