[LLVMdev] Stackmaps: caller-save-registers passed as deopt args

[Kevin Modzelewski]

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.

[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".]

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.

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.

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.

kmod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/ec3898fa/attachment.html>