Rodrigo Mesquita pushed to branch wip/romes/top-level-bcos-tag at Glasgow Haskell Compiler / GHC Commits: 0784224f by Rodrigo Mesquita at 2025-05-21T18:56:32+01:00 More docs - - - - - 3 changed files: - compiler/GHC/ByteCode/Types.hs - rts/Interpreter.c - rts/StgMiscClosures.cmm Changes: ===================================== compiler/GHC/ByteCode/Types.hs ===================================== @@ -173,11 +173,80 @@ newtype AddrPtr = AddrPtr (RemotePtr ()) -------------------------------------------------------------------------------- Note [Case continuation BCOs] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Consider the following stack with a BCO stack frame at the top: + + (an StgBCO) + | ... | +---> +---------[1]--+ + +------------------+ | | info_tbl_ptr | ------+ + | OTHER FRAME | | +--------------+ | + +------------------+ | | StgArrBytes* | <--- the byte code + | ... | | +--------------+ | + +------------------+ | | ... | | + | fvs1 | | | + +------------------+ | | + | ... | | (StgInfoTable) | + +------------------+ | +----------+ <---+ + | args1 | | | ... | + +------------------+ | +----------+ + | some StgBCO* | -----+ | type=BCO | + +------------------+ +----------+ + Sp | stg_apply_interp | -----+ | ... | + +------------------+ | + | + | (StgInfoTable) + +----> +--------------+ + | ... | + +--------------+ + | type=RET_BCO | + +--------------+ + | ... | + + +The code for a BCO heap object makes use of arguments and free variables which +can typically be found within the BCO stack frame. In the code, these variables +are referenced via a statically known stack offset (tracked using `BCEnv` in +`StgToByteCode`). + +However, in /case continuation/ BCOs, the code may additionally refer to free +variables that are outside of the BCO's stack frame. Instead, some free +variables of a case continuation BCO may only be found in the stack frame of a +parent BCO: + + f x y = case x of ... -> ... y ... + + ==> + + <ParentBCOFrame> + ... + <CaseContinuationBCOFrame> + +Similarly, references to these non-local/out-of-frame variables are done in +terms of stack offsets, but they rely on the position of another frame to be fixed. +(See Note [PUSH_L underflow] for more information about references to previous frames and nested BCOs) + +TODO + +to arguments or free variables in +the stack using a stack pointer offset . + +A BCO closure is typically headed by the stg_BCO info table pointer. +... + +A BCO can be constructed using the stg_BCO info table, OR using the stg Does the BCO code depend on stack-pointer-relative offsets? ... why ... example + +... + + <parentBCOFrame> + ... + <inserted> + ... + <childBCOFrame> + -} data UnlinkedBCO ===================================== rts/Interpreter.c ===================================== @@ -203,14 +203,14 @@ PUSH_L instruction. |---------| | BCO_1 | -<-┐ -|---------| +|---------| | ......... | |---------| | PUSH_L <n> | BCO_N | ->-┘ |---------| Here BCO_N is syntactically nested within the code for BCO_1 and will result -in code that references the prior stack frame of BCO_1 for some of it's local +in code that references the prior stack frame of BCO_1 for some of its local variables. If a stack overflow happens between the creation of the stack frame for BCO_1 and BCO_N the RTS might move BCO_N to a new stack chunk while leaving BCO_1 in place, invalidating a simple offset based reference to the outer stack @@ -524,14 +524,35 @@ interpretBCO (Capability* cap) // // We have a BCO application to perform. Stack looks like: // - // | .... | - // +---------------+ - // | arg1 | - // +---------------+ - // | BCO | - // +---------------+ - // Sp | RET_BCO | - // +---------------+ + // + // (an StgBCO) + // +---> +---------[1]--+ + // | | stg_BCO_info | ------+ + // | +--------------+ | + // | | StgArrBytes* | <--- the byte code + // | ... | | +--------------+ | + // +------------------+ | | ... | | + // | fvs1 | | | + // +------------------+ | | + // | ... | | (StgInfoTable) | + // +------------------+ | +----------+ <---+ + // | args1 | | | ... | + // +------------------+ | +----------+ + // | some StgBCO* | -----+ | type=BCO | + // +------------------+ +----------+ + // Sp | stg_apply_interp | -----+ | ... | + // +------------------+ | + // | + // | (StgInfoTable) + // +----> +--------------+ + // | ... | + // +--------------+ + // | type=RET_BCO | + // +--------------+ + // | ... | + // + // [1] An StgBCO's info table pointer may also be stg_CASE_CONT_BCO_info. + // See Note [Case continuation BCOs]. // else if (SpW(0) == (W_)&stg_apply_interp_info) { obj = UNTAG_CLOSURE((StgClosure *)ReadSpW(1)); ===================================== rts/StgMiscClosures.cmm ===================================== @@ -469,6 +469,7 @@ INFO_TABLE_RET( stg_dead_thread, RET_SMALL, non-local variables in its code (using a stack offset) and those that do not. Only case-continuation BCOs should use non-local variables. Otherwise, `stg_BCO` and `stg_CASE_CONT_BCO` behave the same. + See Note [Case continuation BCOs]. ------------------------------------------------------------------------- */ INFO_TABLE_FUN( stg_BCO, 3, 0, BCO, "BCO", "BCO", 0, ARG_BCO ) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/0784224fbcd1c7a7c16b9812b1e4445d... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/0784224fbcd1c7a7c16b9812b1e4445d... You're receiving this email because of your account on gitlab.haskell.org.