[llvm-dev] Statepoints with non SP-relative addresses

[Sanjoy Das via llvm-dev]

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