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

Sanjoy Das sanjoy at playingwithpointers.com
Thu Nov 6 18:23:42 PST 2014


> That's an elegant approach to avoiding the backend problems. The IR
> representation makes perfect sense. I think your deopt mechanism would
> need to patch the return address as if an exception were thrown (I
> guess that’s what you mean by “throwing an exception”).

Yes.

> Also, you will
> end up with exception tables that need to be parsed in addition to
> stackmaps, which seems fairly horrible. Agree?

Agreed.  We have to figure out how to parse exception tables anyway if
we wish to do zero-cost exception handling using something like the
C++ ABI.

The interesting thing is modeling deoptimization as an "exceptional
situation" may have positive performance implications.  For example,
we can teach the optimizer to aggressively sink computation into these
"deoptimization landingpads", so values needed only in case of
deoptimization don't get computed on the normal path.

> I assume that statepoints have the same issue with both deopt values
> and GC roots once you stop spilling them. Do you have a preferred or
> tentative solution for it?

Yes, statepoints are sound w.r.t deoptimization state only if we can
convince the backend to put deopt state in preserved locations (callee
saved registers, stack slots etc.).

However, we may prefer the "deoptimizing by exception throw" approach
if that helps performance.  We haven't yet looked into this issue in
depth, but it seems like an interesting approach.

-- Sanjoy




More information about the llvm-dev mailing list