1. 04 Jun, 2020 1 commit
    • John Ericson's avatar
      Clean up boot vs non-boot disambiguating types · 32a4ae90
      John Ericson authored
      We often have (ModuleName, Bool) or (Module, Bool) pairs for "extended"
      module names (without or with a unit id) disambiguating boot and normal
      modules. We think this is important enough across the compiler that it
      deserves a new nominal product type. We do this with synnoyms and a
      functor named with a `Gen` prefix, matching other newly created
      definitions.
      
      It was also requested that we keep custom `IsBoot` / `NotBoot` sum type.
      So we have it too. This means changing many the many bools to use that
      instead.
      
      Updates `haddock` submodule.
      32a4ae90
  2. 24 May, 2020 1 commit
  3. 30 Apr, 2020 1 commit
  4. 26 Apr, 2020 1 commit
  5. 18 Apr, 2020 1 commit
    • Sylvain Henry's avatar
      Modules (#13009) · 15312bbb
      Sylvain Henry authored
      * SysTools
      * Parser
      * GHC.Builtin
      * GHC.Iface.Recomp
      * Settings
      
      Update Haddock submodule
      
      Metric Decrease:
          Naperian
          parsing001
      15312bbb
  6. 07 Apr, 2020 1 commit
  7. 29 Mar, 2020 2 commits
    • Sylvain Henry's avatar
      Store ComponentId details · e54500c1
      Sylvain Henry authored
      As far as GHC is concerned, installed package components ("units") are
      identified by an opaque ComponentId string provided by Cabal. But we
      don't want to display it to users (as it contains a hash) so GHC queries
      the database to retrieve some infos about the original source package
      (name, version, component name).
      
      This patch caches these infos in the ComponentId itself so that we don't
      need to provide DynFlags (which contains installed package informations)
      to print a ComponentId.
      
      In the future we want GHC to support several independent package states
      (e.g. for plugins and for target code), hence we need to avoid
      implicitly querying a single global package state.
      e54500c1
    • Sylvain Henry's avatar
      Modules: Types (#13009) · 1941ef4f
      Sylvain Henry authored
      Update Haddock submodule
      
      Metric Increase:
         haddock.compiler
      1941ef4f
  8. 12 Mar, 2020 2 commits
    • Sylvain Henry's avatar
      Use a Set to represent Ways · a6989971
      Sylvain Henry authored
      Should make `member` queries faster and avoid messing up with missing
      `nubSort`.
      
      Metric Increase:
          hie002
      a6989971
    • Sylvain Henry's avatar
      Refactor GHC.Driver.Session (Ways and Flags) · 8e6febce
      Sylvain Henry authored
      * extract flags and ways into their own modules (with some renaming)
      
      * remove one SOURCE import of GHC.Driver.Session from GHC.Driver.Phases
      
      * when GHC uses dynamic linking (WayDyn), `interpWays` was only
        reporting WayDyn even if the host was profiled (WayProf).  Now it
        returns both as expected (might fix #16803).
      
      * `mkBuildTag :: [Way] -> String` wasn't reporting a canonical tag for
        differently ordered lists. Now we sort and nub the list to fix this.
      8e6febce
  9. 22 Feb, 2020 1 commit
  10. 12 Feb, 2020 1 commit
  11. 08 Feb, 2020 1 commit
  12. 13 Jan, 2020 1 commit
  13. 06 Jan, 2020 1 commit
  14. 16 Oct, 2019 1 commit
  15. 05 Oct, 2019 1 commit
  16. 01 Oct, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Refactor iface file generation: · f3cb8c7c
      Ömer Sinan Ağacan authored
      This commit refactors interface file generation to allow information
      from the later passed (NCG, STG) to be stored in interface files.
      
      We achieve this by splitting interface file generation into two parts:
      * Partial interfaces, built based on the result of the core pipeline
      * A fully instantiated interface, which also contains the final
      fingerprints and can optionally contain information produced by the backend.
      
      This change is required by !1304 and !1530.
      
      -dynamic-too handling is refactored too: previously when generating code
      we'd branch on -dynamic-too *before* code generation, but now we do it
      after.
      
      (Original code written by @AndreasK in !1530)
      
      Performance
      ~~~~~~~~~~~
      
      Before this patch interface files where created and immediately flushed
      to disk which made space leaks impossible.
      With this change we instead use NFData to force all iface related data
      structures to avoid space leaks.
      
      In the process of refactoring it was discovered that the code in the
      ToIface Module allocated a lot of thunks which were immediately forced
      when writing/forcing the interface file. So we made this module more
      strict to avoid creating many of those thunks.
      
      Bottom line is that allocations go down by about ~0.1% compared to
      master.
      Residency is not meaningfully different after this patch.
      Runtime was not benchmarked.
      Co-Authored-By: Andreas Klebinger's avatarAndreas Klebinger <klebinger.andreas@gmx.at>
      Co-Authored-By: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omer@well-typed.com>
      f3cb8c7c
  17. 09 Sep, 2019 1 commit
    • Daniel Gröber (dxld)'s avatar
      Use lazyness for FastString's z-encoding memoization · 4cf91d1a
      Daniel Gröber (dxld) authored
      Having an IORef in FastString to memoize the z-encoded version is
      unecessary because there is this amazing thing Haskell can do natively,
      it's called "lazyness" :)
      
      We simply remove the UNPACK and strictness annotations from the constructor
      field corresponding to the z-encoding, making it lazy, and store the
      (pure) z-encoded string there.
      
      The only complication here is 'hasZEncoding' which allows cheking if a
      z-encoding was computed for a given string. Since this is only used for
      compiler performance statistics though it's not actually necessary to have
      the current per-string granularity.
      
      Instead I add a global IORef counter to the FastStringTable and use
      unsafePerformIO to increment the counter whenever a lazy z-encoding is
      forced.
      4cf91d1a
  18. 02 Jul, 2019 1 commit
  19. 11 Jun, 2019 1 commit
    • Alp Mestanogullari's avatar
      Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETER · 39f50bff
      Alp Mestanogullari authored
      As discussed in #16331, the GHCI macro, defined through 'ghci' flags
      in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
      whether GHC is built with support for an internal interpreter, that runs in
      the same process. It is however overloaded in a few places to mean
      "there is an interpreter available", regardless of whether it's an internal
      or external interpreter.
      
      For the sake of clarity and with the hope of more easily being able to
      build stage 1 GHCs with external interpreter support, this patch splits
      the previous GHCI macro into 3 different ones:
      
      - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
      - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
      - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
      39f50bff
  20. 15 Mar, 2019 1 commit
  21. 03 Feb, 2019 1 commit
  22. 22 Nov, 2018 1 commit
  23. 28 Oct, 2018 1 commit
    • Zejun Wu's avatar
      Rewrite FastString table in concurrent hashtable · 5126764b
      Zejun Wu authored
      Summary:
      Reimplement global FastString table using a concurrent hashatable with
      fixed size segments and dynamically growing buckets instead of fixed size
      buckets.
      
      This addresses the problem that `mkFastString` was not linear when the
      total number of entries was large.
      
      Test Plan:
      ./validate
      
      ```
      inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null
      GHCi, version 8.7.20181005: http://www.haskell.org/ghc/  :? for help
      Prelude> Leaving GHCi.
      FastString stats:
          segments:          256
          buckets:           16384
          entries:           7117
          largest segment:   64
          smallest segment:  64
          longest bucket:    5
          has z-encoding:    0%
      ```
      
      Also comapre the two implementation using
      
      {P187}
      
      The new implementation is on a par with the old version with different
      conbination of parameters and perform better when the number of
      FastString's are large.
      
      {P188}
      
      Reviewers: simonmar, bgamari, niteria
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #14854
      
      Differential Revision: https://phabricator.haskell.org/D5211
      5126764b
  24. 30 Jul, 2018 1 commit
  25. 27 Jul, 2018 1 commit
    • Michael Sloan's avatar
      Modifications to support loading GHC into GHCi · 60ecf43a
      Michael Sloan authored
      This change was previously part of
      [D4904](https://phabricator.haskell.org/D4904), but is being split off
      to aid in getting this reviewed and merged.
      
      * The compiler code is built with `NoImplicitPrelude`, but GHCi's
        modules are incompatible with it. So, this adds the pragma to all GHCi
        modules that didn't have it, and adds imports of Prelude.
      
      * In order to run GHC within itself, a `call of 'initGCStatistics`
        needed to be skipped. This uses CPP to skip it when
        `-DGHC_LOADED_INTO_GHCI` is set.
      
      * There is an environment variable workaround suggested by Ben Gamari
        [1], where `_GHC_TOP_DIR` can be used to specify GHC's top dir if `-B`
        isn't provided.  This can be used to solve a problem where the GHC being
        run within GHCi attempts to look in `inplace/lib/lib/` instead of
        `inplace/lib/`.
      
      [1]: https://phabricator.haskell.org/D4904#135438
      
      Reviewers: goldfire, bgamari, erikd, alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: alpmestan, lelf, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4986
      60ecf43a
  26. 14 May, 2018 1 commit
  27. 11 Dec, 2017 1 commit
    • David Feuer's avatar
      Allow users to ignore optimization changes · 708ed9ca
      David Feuer authored
      * Add a new flag, `-fignore-optim-changes`, allowing them to avoid
        recompilation if the only changes are to the `-O` level or to
        flags controlling optimizations.
      
      * When `-fignore-optim-changes` is *off*, recompile when optimization
        flags (e.g., `-fno-full-laziness`) change. Previously, we ignored
        these unconditionally when deciding whether to recompile a module.
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: duog, carter, simonmar, rwbarton, thomie
      
      GHC Trac Issues: #13604
      
      Differential Revision: https://phabricator.haskell.org/D4123
      708ed9ca
  28. 30 Oct, 2017 1 commit
  29. 21 Sep, 2017 1 commit
  30. 12 Jun, 2017 1 commit
  31. 04 May, 2017 1 commit
  32. 29 Apr, 2017 1 commit
  33. 23 Feb, 2017 1 commit
  34. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  35. 18 Jan, 2017 1 commit
  36. 18 Oct, 2016 1 commit
  37. 14 Oct, 2016 1 commit
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  38. 08 Oct, 2016 1 commit