llvm dev - Jun 2016 - Statepoints with non SP-relative addresses

Hi all,

Is there a particular reason for statepoints to only reference stack
memory relatively to the stack pointer ?

This came up in the following configuration :
- the frame lowering decides that !hasReservedCallFrame
- the call has a static alloca in the deopt bundle
- the call has enough arguments to require spilling some to the stack
In that case the stackmap will contain an entry that ignores the
adjustments to SP made by the lowering around the call and does not
point to the right address.
Even though this looks like a bug and could probably be fixed, the
following simple patch seem to be enough as it lets the target pick
the register. As far as I can tell it correctly uses BP when
necessary.
> diff --git a/lib/CodeGen/PrologEpilogInserter.cpp
b/lib/CodeGen/PrologEpilogInserter.cpp
> index be3e5e2..6064e6f 100644
> --- a/lib/CodeGen/PrologEpilogInserter.cpp
> +++ b/lib/CodeGen/PrologEpilogInserter.cpp
> @@ -1094,7 +1094,7 @@ void PEI::replaceFrameIndices(MachineBasicBlock *BB,
MachineFunction &Fn,
>          unsigned Reg;
>          MachineOperand &Offset = MI->getOperand(i + 1);
>          const unsigned refOffset > -         
TFI->getFrameIndexReferenceFromSP(Fn, MI->getOperand(i).getIndex(),
> +          TFI->getFrameIndexReference(Fn,
MI->getOperand(i).getIndex(),
>                                              Reg);
>
>          Offset.setImm(Offset.getImm() + refOffset);
I'm also wondering if there is any guarantee that this would work in
all the possible call frame configurations (variable length alloca,
stack realignment, ...).

Thanks !
Oscar

Hi Oscar,

On Tue, Jun 7, 2016 at 6:08 AM, Oscar Blumberg via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Is there a particular reason for statepoints to only reference stack
> memory relatively to the stack pointer ?
Mostly to help the runtimes consuming the __llvm_stackmaps section --
it is easier to have to deal with only one kind of offset.
> This came up in the following configuration :
> - the frame lowering decides that !hasReservedCallFrame
> - the call has a static alloca in the deopt bundle
> - the call has enough arguments to require spilling some to the stack
> In that case the stackmap will contain an entry that ignores the
> adjustments to SP made by the lowering around the call and does not
> point to the right address.
> Even though this looks like a bug and could probably be fixed, the
I agree with this assessment -- this looks like a bug in
getFrameIndexReferenceFromSP.  As long as it is possible for it to
return a correct SP offset, it should do so.  If it isn't possible to
give out an RSP relative address then it should assert instead of
giving out a bad offset.  So it is a bug either way. :)
> following simple patch seem to be enough as it lets the target pick
> the register. As far as I can tell it correctly uses BP when
> necessary.
Ideally we should not give out an RBP-relative offset unless we have
to.  In some cases avoiding RBP offsets is not possible (e.g. the
situations you highlighted we _need_ a variably sized frame), and in
those cases I think it is okay to gracefully degrade to using RBP.

Now it may already be the case that getFrameIndexReference returns a
non-SP relative offset only when absolutely necessary, in which case
your change makes sense.  However, I don't want LLVM reporting a
BP-relative offset just because, say, we disabled frame pointer
elimination and it is _possible_ but not _necessary_ to report a
BP-relative offset.

Thanks!
-- Sanjoy