Stack package:ghc
Utilities and wrappers for Stack manipulation in JS Land.
In general, functions suffixed with a tick do the actual work,
functions suffixed with an
I are identical to the non-I
versions but work on
Idents
The stack in JS land is held in the special JS array 'h$stack' and the
stack pointer is held in 'h$sp'. The top of the stack thus exists at
'h$stack[h$sp]'. h$stack[h$sp + i] where i > 0, moves deeper into
the stack into older entries, whereas h$stack[h$sp - i] moves towards
the top of the stack.
The stack layout algorithm is slightly peculiar. It makes an effort to
remember recently popped things so that if these values need to be
pushed then they can be quickly. The implementation for this is
storing these values above the stack pointer, and the pushing will
skip slots that we know we will use and fill in slots marked as
unknown. Thus, you may find that our push and pop functions do some
non-traditional stack manipulation such as adding slots in pop or
removing slots in push.
The assignment of virtual registers to stack slots
Identifier for a stack slot.
The closure is a stack frame
A Stack Slot is either known or unknown. We avoid maybe here for more
strictness.
The number of bytes that the stack pointer should be aligned to.
LR and FP (8 byte each) are the prologue of each stack frame
The size of a minimal stackframe header including minimal parameter
save area.
Stack frame header size in bytes.
The stack frame header is made of the values that are always saved
(regardless of the context.) It consists of the saved return address
and a pointer to the previous frame. Thus, its size is two stack frame
slots which equals two addresses/words (2 * 8 byte).
Assignment of vregs to stack slots.
The slots that are still available to be allocated.
Id values The
rootN node is the root (there can be more than
one) of the TBAA hierarchy and as of LLVM 4.0 should *only* be
referenced by other nodes. It should never occur in any LLVM
instruction statement.