Skip to content
Snippets Groups Projects
  1. Mar 19, 2024
    • Matthew Craven's avatar
      CorePrep: Rework lowering of BigNat# literals · b56d2761
      Matthew Craven authored and Marge Bot's avatar Marge Bot committed
      Don't use bigNatFromWord#, because that's terrible:
       * We shouldn't have to traverse a linked list at run-time
         to build a BigNat# literal. That's just silly!
       * The static List object we have to create is much larger
         than the actual BigNat#'s contents, bloating code size.
       * We have to read the corresponding interface file,
         which causes un-tracked implicit dependencies. (#23942)
      
      Instead, encode them into the appropriate platform-dependent
      sequence of bytes, and generate code that copies these bytes
      at run-time from an Addr# literal into a new ByteArray#.
      A ByteArray# literal would be the correct thing to generate,
      but these are not yet supported; see also #17747.
      
      Somewhat surprisingly, this change results in a slight
      reduction in compiler allocations, averaging around 0.5%
      on ghc's compiler performance tests, including when compiling
      programs that contain no bignum literals to begin with.
      The specific cause of this has not been investigated.
      
      Since this lowering no longer reads the interface file for
      GHC.Num.BigNat, the reasoning in Note [Depend on GHC.Num.Integer]
      is obsoleted.  But the story of un-tracked built-in dependencies
      remains complex, and Note [Tracking dependencies on primitives]
      now exists to explain this complexity.
      
      Additionally, many empty imports have been modified to refer to
      this new note and comply with its guidance.  Several empty imports
      necessary for other reasons have also been given brief explanations.
      
      Metric Decrease:
          MultiLayerModulesTH_OneShot
      b56d2761
  2. Mar 09, 2024
  3. Mar 08, 2024
  4. Mar 06, 2024
  5. Feb 27, 2024
  6. Feb 25, 2024
  7. Feb 17, 2024
  8. Feb 16, 2024
  9. Feb 15, 2024
  10. Feb 08, 2024
    • Ben Gamari's avatar
      Move `base` to `ghc-internal` · 44f6557a
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Here we move a good deal of the implementation of `base` into a new
      package, `ghc-internal` such that it can be evolved independently
      from the user-visible interfaces of `base`.
      
      While we want to isolate implementation from interfaces, naturally, we
      would like to avoid turning `base` into a mere set of module re-exports.
      However, this is a non-trivial undertaking for a variety of reasons:
      
       * `base` contains numerous known-key and wired-in things, requiring
         corresponding changes in the compiler
      
       * `base` contains a significant amount of C code and corresponding
         autoconf logic, which is very fragile and difficult to break apart
      
       * `base` has numerous import cycles, which are currently dealt with via
         carefully balanced `hs-boot` files
      
       * We must not break existing users
      
      To accomplish this migration, I tried the following approaches:
      
      * [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental
        migration of modules into ghc-internal: this knot is simply too
        intertwined to be easily pulled apart, especially given the rather
        tricky import cycles that it contains)
      
      * [Move-Core]: Moving the "core" connected component of base (roughly
        150 modules) into ghc-internal. While the Haskell side of this seems
        tractable, the C dependencies are very subtle to break apart.
      
      * [Move-Incrementally]:
      
        1. Move all of base into ghc-internal
        2. Examine the module structure and begin moving obvious modules (e.g.
           leaves of the import graph) back into base
        3. Examine the modules remaining in ghc-internal, refactor as necessary
           to facilitate further moves
        4. Go to (2) iterate until the cost/benefit of further moves is
           insufficient to justify continuing
        5. Rename the modules moved into ghc-internal to ensure that they don't
           overlap with those in base
        6. For each module moved into ghc-internal, add a shim module to base
           with the declarations which should be exposed and any requisite
           Haddocks (thus guaranteeing that base will be insulated from changes
           in the export lists of modules in ghc-internal
      
      Here I am using the [Move-Incrementally] approach, which is empirically
      the least painful of the unpleasant options above
      
      Bumps haddock submodule.
      
      Metric Decrease:
          haddock.Cabal
          haddock.base
      Metric Increase:
          MultiComponentModulesRecomp
          T16875
          size_hello_artifact
      44f6557a
  11. Jan 14, 2024
  12. Jan 07, 2024
  13. Nov 17, 2023
  14. Nov 09, 2023
  15. Nov 01, 2023
  16. Oct 19, 2023
  17. Sep 27, 2023
  18. Sep 01, 2023
  19. Aug 23, 2023
  20. Jul 22, 2023
  21. Jul 08, 2023
Loading