[llvm-dev] llvm.experimental.gc.statepoint genarates wrong Stack Map (or does it?)

[Sanjoy Das via llvm-dev]

Hi Vlad,

vlad via llvm-dev wrote:
 >> Vlad,
 >>
 >> My initial impression is that you've stumbled across a bug. I suspect
 >> that we - the only active users of the deopt info in the statepoint I
 >> know of - have been inverting the meaning of Direct and Indirect
 >> throughout our code. (i.e. we're consistent, but swapped on the
 >> documented meaning) I've asked Sanjoy to confirm that, and if he
 >> believes that is actually the case, we will fix upstream to use
 >> Indirect in this case.
 >>
 >> I'll try to have more information for you early next week.

This is definitely what looks to be going on: we report a stack slot
as "Direct" when the doc says we have to report these as "Indirect".
I'll send in a fix sometime this week.

[Some details below, feel free to skip]

The problem is we reuse emitPatchpoint in
X86TargetLowering::EmitInstrWithCustomInserter even though
patchpoint's notion of what needs to be Direct vs. what needs to be
Indirect is different from ours.  Specifically, emitPatchpoint will
take any FrameIndex machine operand and report it as Direct, and will
only use Indirect for memory operands that it could fold into the
PATCHPOINT node i.e. PATCHPOINT(load_addr(%rsp + 40)) gets reported as
an Indirect location [RSP+40], but PATCHPOINT(%rsp + 40) gets reported
as Direct.  For us, logically, we've already done the "folding"
earlier, so the above behavior isn't quite right for us.

 > May be it's a separate question, but I hope it's OK to ask in this
 > thread. Would it be hard to make the statepoint intrinsic produce frame
 > pointer based offset (instead of sp-based) if
 > "no-frame-pointer-elim"="true" attribute is specified?

For non-aligned frames (i.e. frames that don't align themselves) this
shouldn't be fundamentally difficult, but there are some tricky math
around frame layout you'll have to get right.

For aligned frames, I'm not sure if there is a way to get to all of
the stack locations using RBP (assuming it contains the "SP at entry"
value as usual).  But please do check.

 >> Can I ask what you're using the deopt information for? Do you have a
 >> language runtime which supports deoptimization? Or are you using it
 >> for something different? If so, what? I'm curious to know how others
 >> are using the infrastructure.
 >
 > Sure.
 > I am working on LLV8, which is an attempt to use LLVM MCJIT as a backend
 > for Google V8. So yes, we have a language runtime which supports
 > deoptimization.
 > Deoptimization support wasn't hard. We use the stackmap intrinsic for
 > that. (And we've encountered each type of Location except Direct so far).
 > Now I am implementing the safepoint functionality which is why I use the
 > gc.statepoint intrinsic. The two utility passes have been extremely
 > helpful. The use-cases they support are much more general than my needs
 > though. So I use a modified version of RewriteStatepointsForGC, which
 > only appends the pointer values live across the statepoint to <deopt 
args>.

If I understand you correctly, that will work only if your GC isn't a
relocating GC.  Is that the case?

-- Sanjoy