[LLVMdev] Patchpoints used for inline caches and pointless reloads

[Frej Drejhammar]

Philip Reames <listmail at philipreames.com> writes:

> Just to make sure we're on the same page, let me try to rephrase your
> problem:
> "After the initial call is patched out of existence, the register
> spilling which was reasonable for the initial call becomes a
> performance liability for the patched in assembly."
>
> Is that a correct restatement?

That is correct.

> If so, I'd suggest you look into not using the anyregcc convention. My
> understand is that that convention is intended for calls where values
> are desired in registers over the call.  This is not what you want.
>
> If you used the standard C convention, the calling convention would
> place the first X (where X is 6 I think) arguments in registers and
> the rest on the stack.  If you pad your actual arguments with undef
> such that the arguments that are used by your patch mechanism are
> after that threshold, you might see what you're looking for. However,
> I suspect you'd still see a move from the stack to a register, and
> then back to a different slot due the calling convention adjustments.

Or even worse, if among the input to the patch mechanism are arguments
to the function containing the patch-point, I will probably get a copy
from the caller's stack frame to the callee's. Also as the patch
mechanism looks at values which are "hot" I still want to access them
where they are (hopefully in registers) and not force them into
stack-slots, or into registers dictated by the calling convention.

> What I think you really want is a parameter attribute that we don't
> have.  You want to be able to tag a particular parameter as being
> "anylocation" (analogous to the anyreg of anyregcc).  In concept, a
> "anystack" notion is similar to what we do for gc.statepoints (and, I
> think, excess arguments on patchpoints?).  That's still not quite as
> strong as what you want though...

Since I sent the original email I have been working on a pass inspired
by LiveDebugVariables. Before register allocation it notes the virtual
register for each non-lowered patchpoint operand and then replaces the
operand with an immediate. During register allocation the pass tracks
the original virtual register and when register allocation is complete,
the operands are replaced with a physical register or a stack slot. That
way the arguments to the patchpoint does not influence register
allocation at all, i.e. when the patchpoint call is patched out it will
be as if it never existed.

Instead of treating all non-lowered operands like this, I can simply
limit it to parameters marked with an "anylocation" parameter
attribute. That is a good suggestion for extending the patchpoint
behavior.

> If you do decide to pursue the "anylocation" parameter attribute,
> definitely keep me informed. This is analogous to something we want
> for gc.statepoints as well.

I'll be happy to send you my current patch off-list if you are
interested. I'll definitely add you as a reviewer when I try to push it
upstream. Can you tell me more about what it is you want for
gc.statepoints?

> p.s. Without knowing what DB actually is, it really looks like you
> might be able to accomplish the same thing using the "ID" field of the
> patchpoint.  Have you looked into that?

Sure, an extra indirection solves all problems in CS :) But it is not
that simple if, for example, values the patch mechanism needs are passed
as arguments to function containing the patchpoint.

Cheers,

--Frej