<div dir="ltr">This is a follow up on a conversation some of us had at the hacker lab -- I noticed that sometimes I will get notified that a deopt value lives in a register that is not callee-save (caller-save I guess, but is there another term for this that is less similar to callee-save?).  This surprised me quite a bit since those registers immediately got clobbered by the call inside the patchpoint, so we were discussing whether this is the appropriate behavior or not.<div><div><br></div><div>[Another point about terminology -- the stackmaps documentation refers to the non-function-call arguments as "live values", but we were calling them "deopt values" in person, and I don't particularly like either term, since we also have "live outs" which deal with a separate problem, and for Pyston we pass some non-deopt-values in this section.  It might be worth nailing down a term for this -- personally I call them "stackmap arguments" and the initial arguments "function arguments".]</div><div><br></div><div>In the cases I'm running into, the value lives in both a register and on the stack, and the stackmap code seems to preferentially give the register even if it is a caller-save register.  In our discussion, it seemed like another possible situation is if the value only lives in a caller-save register, if it is not used after that patchpoint.  So the questions are: should we prefer a stack slot to caller-save registers, and should we prefer them enough to emit a spill if necessary?  I think the answers to both should be yes.  I think LLVM should emit the spill because otherwise the client's patchpoint-initialization logic will have to do that; that's fine, but it means that one has to reserve nops for spilling in every patchpoint, whereas LLVM will emit the spill code when necessary.</div><div><br></div><div>There was some discussion about what the behavior should be if you use anyregcc, since in that case it seems reasonable to receive a caller-save register if you are interested in using it inside the patchpoint.  My thoughts are that in that case you might be better off including the value as part of the function arguments instead of the stackmap/deopt arguments.  I think Philip had some more thoughts about how the calling convention of the patchpoint should apply to the deopt args.</div><div><br></div><div>So concretely, I think we should change the lowering so that (other than anyregcc) the deopt args always get passed on the stack or in callee save registers, even if it requires adding spills.  I think some of the other people in the discussion had a better idea about how to potentially implement that than I did.</div><div><br></div><div>kmod</div></div></div>