Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

I like the idea. It would be interesting to collect data on the number of spills/unspills we see (with/without minopts) to get an idea of how much additional IR it would introduce.

Would the new nodes have their own codegen or would they be handled as part of the consuming node? For example, GT_RELOAD already exists today with the latter semantics, from lsra-detail.md:

... if the value must be reloaded to a different register than the one specified on the tree node (which is the one used when the node is evaluated), LSRA must insert a GT_RELOAD node to specify the register to which it should be reloaded.

which sounds very similar to this idea.

It is not completely obvious to me what the IR nodes would end up looking like, especially for the multireg node cases. Do you have any examples of what you were thinking?

There is also the question of how reg-optional uses would be represented, e.g. GenTree::isUsedFromSpillTemp today relies on GTF_SPILLED. Perhaps LSRA could rephrase these uses in terms of containment, so that it would replace spilled reg-optional operands with a contained GT_UNSPILL/GT_RELOAD.

Definitely some more research is needed here.

I would expect the new nodes would have their own codegen and would not be contained.

GT_RELOAD is already used, but only in some situations where the GTF_SPILLED bit couldn't be used (IIUC).

Thanks for pointing out the isUsedFromSpillTemp case: it seems like that, too, should be removed. LSRA should insert the correct reference (maybe a new GT_TEMP_VAR if necessary? or LCL_VAR with a distinguished varNum (negative)?)