is there some canonical way to extend liveness?

In other compilers I’ve worked on there were special pseudo instructions (or similar mechanisms like adding extra source operands to returns) that allowed you to artificially extend lifetimes of values. For instance we might have a requirement that a certain local (say the ‘this pointer’) remain live throughout the method.

Is there anything like this in LLVM?

There isn’t a generic mechanism for this, but SI uses a custom pass and pseudos to accomplish this. See lib/Target/R600/SIFixSGPRLiveRanges.cpp

Do you need this at the IR level? Or in codegen?

In the IR we use SSA, so variables are live exactly as long as they could
be used. There isn't a way to extend lifetimes in the IR per se, you would
need to mark it used in some fashion. For instance adding an intrinsic
@llvm.gc.range.ends.here(%ssavar) and the value needs to live long enough
for that intrinsic to be called. I suppose if it gets called twice, the
subsequent calls are no-ops.

Matt's answer is good if you want it in codegen. Most of the use-cases I
can think of apply to codegen anyways.

Nick

I’m assuming that you’re asking this in the context of GC? Are you doing conservative stack scanning?

One way you could address this would be to place a gc.statepoint immediately before the return with the value you need held live mentioned. This would also give you a precise stackmap at that location (for the variables explicitly listed).

Philip

Yes, one of the cases comes from GC – at times the code generator must ensure a particular reference is live and reported at every safepoint. This is in the context of a precise GC, though there’s also a conservative mode that we plan to use initially until we get the precise GC reporting correct. Either way that reference must remain live.

We haven’t yet decided when or how we’ll insert safepoints, though we had been thinking of doing it fairly early on to provide some opportunity for optimizers to reason about them.

If I understand the proposal for gc.statepoint correctly, this would be a degenerate case with no function to call and no use of the relocated value.

Ok, glad we’re on the same page. If you want, I’m happy to chat in person or phone about some of the tradeoffs here. We could also stick to email, but I find that involved back and forth discussions tend to be easier with voice. Yes. It’s not really a case we’d thought about per se. If you want to poll on return, this is easy. If you want it to just hold something live, but otherwise not actually call anything, we’d have to implement something to get good code gen. Providing a dummy function which you called would be a good way to get started.