Skip to content
  • Rodrigo Mesquita's avatar
    5c2a179e
    Allocate static constructors for bytecode · 5c2a179e
    Rodrigo Mesquita authored and Marge Bot's avatar Marge Bot committed
    This commit adds support for static constructors when compiling and
    linking ByteCode objects.
    
    Top-level StgRhsCon get lowered to ProtoStaticCons rather than to
    ProtoBCOs. A ProtoStaticCon gets allocated directly as a data con
    application on the heap (using the new primop newConApp#).
    
    Previously, we would allocate a ProtoBCO which, when evaluated, would
    PACK and return the constructor.
    A few more details are given in Note [Static constructors in Bytecode].
    
    Secondly, this commit also fixes issue #25636 which was caused by
    linking *unlifted* constructors in BCO instructions as
        - (1) a thunk indexing the array of BCOs in a module
        - (2) which evaluated to a BCO which still had to be evaluated to
          return the unlifted constructor proper.
    
    The (2) issue has been resolved by allocating the static constructors
    directly. The (1) issue can be resolved by ensuring that we allocate all
    unlifted top-level constructors eagerly, and leave the knot-tying for
    the lifted BCOs and top-level constructors only.
    
    The top-level unlifted constructors are never mutually recursive, so we
    can allocate them all in one go as long as we do it in topological
    order. Lifted fields of unlifted constructors can still be filled by the
    knot-tied lifted variables since in those fields it is fine to keep
    those thunks. See Note [Tying the knot in createBCOs] for more details.
    
    Fixes #25636
    
    -------------------------
    Metric Decrease:
        LinkableUsage01
    -------------------------
    5c2a179e
    Allocate static constructors for bytecode
    Rodrigo Mesquita authored and Marge Bot's avatar Marge Bot committed
    This commit adds support for static constructors when compiling and
    linking ByteCode objects.
    
    Top-level StgRhsCon get lowered to ProtoStaticCons rather than to
    ProtoBCOs. A ProtoStaticCon gets allocated directly as a data con
    application on the heap (using the new primop newConApp#).
    
    Previously, we would allocate a ProtoBCO which, when evaluated, would
    PACK and return the constructor.
    A few more details are given in Note [Static constructors in Bytecode].
    
    Secondly, this commit also fixes issue #25636 which was caused by
    linking *unlifted* constructors in BCO instructions as
        - (1) a thunk indexing the array of BCOs in a module
        - (2) which evaluated to a BCO which still had to be evaluated to
          return the unlifted constructor proper.
    
    The (2) issue has been resolved by allocating the static constructors
    directly. The (1) issue can be resolved by ensuring that we allocate all
    unlifted top-level constructors eagerly, and leave the knot-tying for
    the lifted BCOs and top-level constructors only.
    
    The top-level unlifted constructors are never mutually recursive, so we
    can allocate them all in one go as long as we do it in topological
    order. Lifted fields of unlifted constructors can still be filled by the
    knot-tied lifted variables since in those fields it is fine to keep
    those thunks. See Note [Tying the knot in createBCOs] for more details.
    
    Fixes #25636
    
    -------------------------
    Metric Decrease:
        LinkableUsage01
    -------------------------
Loading