[llvm-dev] ABI-specific Stack Pointer Register?
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 6 15:08:10 PST 2019
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...
More information about the llvm-dev