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

[Andrew Trick]

> On Oct 31, 2014, at 5:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
> Hi Kevin,
> 
> Thank you for starting this discussion!

Yes, sorry for being unresponsive for a few days. Sanjoy summarized the issues perfectly.

> I think the distinction is really between whether the live values are
> "live on call" or "live on return".  Ideally we should be able to mark
> values to be of either kind (liveoncall vs. liveonreturn) in the call
> to the patchpoint intrinsic.  This will make the semantics of
> patchpoint slightly odd though -- we'll end up with an SSA instruction
> where some inputs are expected to be live *after* the instruction has
> been retired.  Are there other SSA instructions that have this sort of
> semantics?

No, it’s a lowering issue. Machine instructions can declare that some registers are early clobbered so that machine operands can’t use that register. In this case it’s best just to think about it as a kind of calling convention though.

>  Nevertheless, I think splitting the inputs to a patchpoint
> into "function arguments", "values live on call" and "values live on
> return" is a good idea.

I basically agree, but think we should have a new intrinsic that is even more general. We should be able to tag any number of arguments as following some convention/lowering rules. Those rules should not be baked into the intrinsic.

What Kevin is asking for is very reasonable and arguably a safer default, but we need the current functionality as well.
As a short term fix, until a new intrinsic is ready, Kevin can add a string attribute to the patchpoint call, say “live-on-return”.

Some work maybe needed to support this. One possibility is to add a machine operand flag that is kind of the inverse of EarlyClobber, say LateUse - that’s hard. An easier option would be to generate a second pseudo instruction immediately after the patchpoint that simply uses all the live-on-return values. A cop-out would be to give the call’s register mask operand a different flag so that is is interpreted as a bunch of early-clobber registers. This last solution would not allow both live-on-return and live-on-call operands in the same call. Hopefully there’s something more clever that I haven’t thought of yet.

>> 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 don't see why anything needs to be different for patchpoints running
> with anyregcc.  The call arguments always get lowered based on the
> calling convention, the "live on call" values get arbitrary stack
> slots / registers and the "live on return" values get assigned to CSRs
> or stack slots.  If I've read X86RegisterInfo::getCalleeSavedRegs
> correctly, I think all registers are callee-saved for anyregcc so
> whatever you call using the anyregcc convention will have to respect
> that; but that's a different problem.

Yep.

-Andy

> 
> Thanks!
> -- Sanjoy