[llvm-dev] ABI-specific Stack Pointer Register?

[Reid Kleckner via llvm-dev]

On Thu, Dec 5, 2019 at 9:35 AM Kavon Farvardin <kavon at farvard.in> wrote:

> On Wed, 2019-12-04 at 12:45 -0800, Reid Kleckner wrote:
>
> From past conversations, I was under the impression that GHC functions are
> really "stackless", they use CPS: they run, perform some computation,
> update the passed-in virtual stack registers, and then return with some
> sort of tail call, preserving and updating the set of registers which were
> passed in. Why does it matter if LLVM spills intermediate data to the
> architectural stack if it clears it all off on exit?
>
>
> The problem is with LLVM's code generation, where some values that could
> be re-materialized (jump table offsets, constants) are instead spilled to
> the architectural stack instead of the virtual stack. Rather than try to
> fix or work round this behavior, I am considering an extension to LLVM in
> concert with GC Statepoints so that the code generator's "architectural"
> stack is the same our "virtual" stack by defining a different ABI, starting
> with a change to the stack pointer register.
>

That's reasonable. Essentially, there are actually points in the frame
where you want parseable state, it's not enough to be parseable only on
entry and exit.


>
> Regarding the feasibility of it, I think it's actually feasible. Depending
> on how radical the changes you need are, I would recommend subclassing the
> TargetFrameLowering classes and providing new implementations of
> emitPrologue, emitEpilogue, and getFrameIndexReference. The X86
> emitPrologue codepath is already very, very complicated, and handles far
> too many special cases. Much of the complexity comes from CFI, and that
> wouldn't be a concern with an alternative stack.
>
>
> My main concern with the changes were around instruction selection being
> dependent on the ABI and the flexibility of frame layout (e.g., where
> register spills go relative to allocas) so that the garbage collector can
> still parse the stack. Do you think there would be any issues there?
>

My understanding is that spill slots are just regular stack objects, so
they'll appear near allocas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191206/0b6aecc0/attachment.html>