Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,247
    • Issues 5,247
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 577
    • Merge requests 577
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Merge requests
  • !4412

Support unboxed tuples and sums in GHCi

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Luite Stegeman requested to merge luite/ghc:wip-stg-ghci into master Nov 05, 2020
  • Overview 148
  • Commits 5
  • Pipelines 55
  • Changes 79

This MR adds support for unboxed tuples and sums in GHCi.

It consists of roughly the following changes:

  • generate bytecode from STG instead of Core (so we can make use of the unarisation step)
  • save the types in Breakpoint annotations (since STG lacks an exprType function and GHCi needs to show the type of breakpoints) (this part is the first commits in this MR and also in the separate MR !4589 (closed))
  • new bytecode instructions RETURN_TUPLE/PUSH_ALTS_TUPLE for returning and receiving an unboxed tuple (or sum)
  • new closures stg_ctoi_t and stg_ret_t for converting tuples between the native (object code) calling convention and bytecode calling convention

Limitation:

Due to the way the stack pointer is handled in the native calling convention, we need an "adjustment frame" that depends on the size of the tuple. The MR includes adjustment frames stg_ctoi_t1 .. stg_ctoi_t62 and as such can handle tuples that use up to 62 stack words (in the native calling convention). It's easy to add more when needed, but it requires GHC and the RTS to be recompiled.

A fully general solution might require changing the native calling convention (in particular where Sp points when returning a tuple)

Edited Mar 14, 2021 by Luite Stegeman
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: wip-stg-ghci