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.