1. 20 Jun, 2019 1 commit
    • John Ericson's avatar
      Move 'Platform' to ghc-boot · bff2f24b
      John Ericson authored
      ghc-pkg needs to be aware of platforms so it can figure out which
      subdire within the user package db to use. This is admittedly
      roundabout, but maybe Cabal could use the same notion of a platform as
      GHC to good affect too.
      bff2f24b
  2. 16 Jun, 2019 1 commit
    • Ryan Scott's avatar
      Synchronize ClsInst.doTyConApp with TcTypeable validity checks (#15862) · 25ee60cd
      Ryan Scott authored
      Issue #15862 demonstrated examples of type constructors on which
      `TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable`
      constraint solver in `ClsInst` (in particular, `doTyConApp`) would
      try to generate `Typeable` evidence for anyway, resulting in
      disaster. This incongruity was caused by the fact that `doTyConApp`
      was using a weaker validity check than `tyConIsTypeable` to determine
      if a type constructor warrants `Typeable` evidence or not. The
      solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in
      `doTyConApp` instead.
      
      To avoid import cycles between `ClsInst` and `TcTypeable`, I factored
      out `tyConIsTypeable` into its own module, `TcTypeableValidity`.
      
      Fixes #15862.
      25ee60cd
  3. 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
  4. 07 Jun, 2019 1 commit
    • Sebastian Graf's avatar
      TmOracle: Replace negative term equalities by refutable PmAltCons · e963beb5
      Sebastian Graf authored
      The `PmExprEq` business was a huge hack and was at the same time vastly
      too powerful and not powerful enough to encode negative term equalities,
      i.e. facts of the form "forall y. x ≁ Just y".
      
      This patch introduces the concept of 'refutable shapes': What matters
      for the pattern match checker is being able to encode knowledge of the
      kind "x can no longer be the literal 5". We encode this knowledge in a
      `PmRefutEnv`, mapping a set of newly introduced `PmAltCon`s (which are
      just `PmLit`s at the moment) to each variable denoting above
      inequalities.
      
      So, say we have `x ≁ 42 ∈ refuts` in the term oracle context and
      try to solve an equality like `x ~ 42`. The entry in the refutable
      environment will immediately lead to a contradiction.
      
      This machinery renders the whole `PmExprEq` and `ComplexEq` business
      unnecessary, getting rid of a lot of (mostly dead) code.
      
      See the Note [Refutable shapes] in TmOracle for a place to start.
      
      Metric Decrease:
          T11195
      e963beb5
  5. 29 May, 2019 1 commit
    • John Ericson's avatar
      Break up `Settings` into smaller structs · ace2e335
      John Ericson authored
      As far as I can tell, the fields within `Settings` aren't *intrinsicly*
      related. They just happen to be initialized the same way (in particular
      prior to the rest of `DynFlags`), and that is why they are grouped
      together.
      
      Within `Settings`, however, there are groups of settings that clearly do
      share something in common, regardless of how they anything is
      initialized.
      
      In the spirit of GHC being a library, where the end cosumer may choose
      to initialize this configuration in arbitrary ways, I made some new data
      types for thoses groups internal to `Settings`, and used them to define
      `Settings` instead. Hopefully this is a baby step towards a general
      decoupling of the stateful and stateless parts of GHC.
      ace2e335
  6. 24 May, 2019 1 commit
    • Michael Sloan's avatar
      Add PlainPanic for throwing exceptions without depending on pprint · d9dfbde3
      Michael Sloan authored
      This commit splits out a subset of GhcException which do not depend on
      pretty printing (SDoc), as a new datatype called
      PlainGhcException. These exceptions can be caught as GhcException,
      because 'fromException' will convert them.
      
      The motivation for this change is that that the Panic module
      transitively depends on many modules, primarily due to pretty printing
      code.  It's on the order of about 130 modules.  This large set of
      dependencies has a few implications:
      
      1. To avoid cycles / use of boot files, these dependencies cannot
      throw GhcException.
      
      2. There are some utility modules that use UnboxedTuples and also use
      `panic`. This means that when loading GHC into GHCi, about 130
      additional modules would need to be compiled instead of
      interpreted. Splitting the non-pprint exception throwing into a new
      module resolves this issue. See #13101
      d9dfbde3
  7. 22 May, 2019 1 commit
  8. 22 Mar, 2019 1 commit
  9. 18 Jan, 2019 1 commit
  10. 16 Jan, 2019 1 commit
    • Alec Theriault's avatar
      Support printing `integer-simple` Integers in GHCi · 582a96f4
      Alec Theriault authored
      This means that `:p` no longer leaks the implementation details of
      `Integer` with `integer-simple`. The `print037` test case should
      exercise all possible code paths for GHCi's code around printing
      `Integer`s (both in `integer-simple` and `integer-gmp`).
      
      `ghc` the package now also has a Cabal `integer-simple` flag (like the
      `integer-gmp` one).
      582a96f4
  11. 01 Jan, 2019 1 commit
  12. 11 Dec, 2018 1 commit
  13. 23 Nov, 2018 1 commit
    • Sebastian Graf's avatar
      Implement late lambda lift · b2950e03
      Sebastian Graf authored
      Summary:
      This implements a selective lambda-lifting pass late in the STG
      pipeline.
      
      Lambda lifting has the effect of avoiding closure allocation at the cost
      of having to make former free vars available at call sites, possibly
      enlarging closures surrounding call sites in turn.
      
      We identify beneficial cases by means of an analysis that estimates
      closure growth.
      
      There's a Wiki page at
      https://ghc.haskell.org/trac/ghc/wiki/LateLamLift.
      
      Reviewers: simonpj, bgamari, simonmar
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #9476
      
      Differential Revision: https://phabricator.haskell.org/D5224
      b2950e03
  14. 19 Nov, 2018 1 commit
    • Sebastian Graf's avatar
      Don't track free variables in STG syntax by default · 47bbc709
      Sebastian Graf authored
      Summary:
      Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non-global
      free variables.  This free variable information is only needed in the final
      code generation step (i.e. `StgCmm.codeGen`), which leads to transformations
      such as `StgCse` and `StgUnarise` having to maintain this information.
      
      This is tiresome and unnecessary, so this patch introduces a trees-to-grow-like
      approach that only introduces the free variable set into the syntax tree in the
      code gen pass, along with a free variable analysis on STG terms to generate
      that information.
      
      Fixes #15754.
      
      Reviewers: simonpj, osa1, bgamari, simonmar
      
      Reviewed By: osa1
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15754
      
      Differential Revision: https://phabricator.haskell.org/D5324
      47bbc709
  15. 17 Nov, 2018 1 commit
    • Andreas Klebinger's avatar
      NCG: New code layout algorithm. · 912fd2b6
      Andreas Klebinger authored
      Summary:
      This patch implements a new code layout algorithm.
      It has been tested for x86 and is disabled on other platforms.
      
      Performance varies slightly be CPU/Machine but in general seems to be better
      by around 2%.
      Nofib shows only small differences of about +/- ~0.5% overall depending on
      flags/machine performance in other benchmarks improved significantly.
      
      Other benchmarks includes at least the benchmarks of: aeson, vector, megaparsec, attoparsec,
      containers, text and xeno.
      
      While the magnitude of gains differed three different CPUs where tested with
      all getting faster although to differing degrees. I tested: Sandy Bridge(Xeon), Haswell,
      Skylake
      
      * Library benchmark results summarized:
        * containers: ~1.5% faster
        * aeson: ~2% faster
        * megaparsec: ~2-5% faster
        * xml library benchmarks: 0.2%-1.1% faster
        * vector-benchmarks: 1-4% faster
        * text: 5.5% faster
      
      On average GHC compile times go down, as GHC compiled with the new layout
      is faster than the overhead introduced by using the new layout algorithm,
      
      Things this patch does:
      
      * Move code responsilbe for block layout in it's own module.
      * Move the NcgImpl Class into the NCGMonad module.
      * Extract a control flow graph from the input cmm.
      * Update this cfg to keep it in sync with changes during
        asm codegen. This has been tested on x64 but should work on x86.
        Other platforms still use the old codelayout.
      * Assign weights to the edges in the CFG based on type and limited static
        analysis which are then used for block layout.
      * Once we have the final code layout eliminate some redundant jumps.
      
        In particular turn a sequences of:
            jne .foo
            jmp .bar
          foo:
        into
            je bar
          foo:
            ..
      
      Test Plan: ci
      
      Reviewers: bgamari, jmct, jrtc27, simonmar, simonpj, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, trommler, jmct, carter, thomie, rwbarton
      
      GHC Trac Issues: #15124
      
      Differential Revision: https://phabricator.haskell.org/D4726
      912fd2b6
  16. 02 Nov, 2018 1 commit
  17. 29 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Bump template-haskell version to 2.15.0.0 · e8a652f6
      Ryan Scott authored
      Summary:
      Commit 512eeb9b
      (`More explicit foralls (GHC Proposal 0007)`) introduced breaking
      changes to the Template Haskell AST. As a consequence of this, there
      are libraries in the wild that now fail to build on GHC HEAD (for
      instance, `th-abstraction`).
      
      This properly bumps the `template-haskell` library's version number
      to `2.15.0.0` so that these libraries can guard against these changes
      using `MIN_VERSION_template_haskell`.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15818
      
      Differential Revision: https://phabricator.haskell.org/D5272
      e8a652f6
  18. 07 Aug, 2018 1 commit
  19. 03 Aug, 2018 1 commit
  20. 16 Jul, 2018 1 commit
    • Simon Marlow's avatar
      Support the GHCi debugger with -fexternal-interpreter · 3bdf0d01
      Simon Marlow authored
      * All the tests in tests/ghci.debugger now pass with
        -fexternal-interpreter. These tests are now run with the ghci-ext way
        in addition to the normal way so we won't break it in the future.
      
      * I removed all the unsafeCoerce# calls from RtClosureInspect. Yay!
      
      The main changes are:
      
      * New messages: GetClosure and Seq.  GetClosure is a remote interface to
        GHC.Exts.Heap.getClosureData, which required Binary instances for
        various datatypes. Fortunately this wasn't too painful thanks to
        DeriveGeneric.
      
      * No cheating by unsafeCoercing values when printing them. Now we have
        to turn the Closure representation back into the native representation
        when printing Int, Float, Double, Integer and Char. Of these, Integer
        was the most painful - we now have a dependency on integer-gmp due to
        needing access to the representation.
      
      * Fixed a bug in rts/Heap.c - it was bogusly returning stack content as
        pointers for an AP_STACK closure.
      
      Test Plan:
      * `cd testsuite/tests/ghci.debugger && make`
      * validate
      
      Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire
      
      Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter
      
      GHC Trac Issues: #13184
      
      Differential Revision: https://phabricator.haskell.org/D4955
      3bdf0d01
  21. 05 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor validity checking for constraints · 45f44e2c
      Simon Peyton Jones authored
      There are several changes here.
      
      * TcInteract has gotten too big, so I moved all the class-instance
        matching out of TcInteract into a new module ClsInst. It parallels
        the FamInst module.
      
        The main export of ClsInst is matchGlobalInst.
        This now works in TcM not TcS.
      
      * A big reason to make matchGlobalInst work in TcM is that we can
        then use it from TcValidity.checkSimplifiableClassConstraint.
        That extends checkSimplifiableClassConstraint to work uniformly
        for built-in instances, which means that we now get a warning
        if we have givens (Typeable x, KnownNat n); see Trac #15322.
      
      * This change also made me refactor LookupInstResult, in particular
        by adding the InstanceWhat field.  I also changed the name of the
        type to ClsInstResult.
      
        Then instead of matchGlobalInst reporting a staging error (which is
        inappropriate for the call from TcValidity), we can do so in
        TcInteract.checkInstanceOK.
      
      * In TcValidity, we now check quantified constraints for termination.
        For example, this signature should be rejected:
           f :: (forall a. Eq (m a) => Eq (m a)) => blah
        as discussed in Trac #15316.   The main change here is that
        TcValidity.check_pred_help now uses classifyPredType, and has a
        case for ForAllPred which it didn't before.
      
        This had knock-on refactoring effects in TcValidity.
      45f44e2c
  22. 20 Jun, 2018 3 commits
  23. 04 Jun, 2018 1 commit
    • Simon Jakobi's avatar
      Serialize docstrings to ifaces, display them with new GHCi :doc command · 85309a3c
      Simon Jakobi authored
      If `-haddock` is set, we now extract docstrings from the renamed ast
      and serialize them in the .hi-files.
      
      This includes some of the changes from D4749 with the notable
      exceptions of the docstring lexing and renaming.
      
      A currently limited and experimental GHCi :doc command can be used
      to display docstrings for declarations.
      
      The formatting of pretty-printed docstrings is changed slightly,
      causing some changes in testsuite/tests/haddock.
      
      Test Plan: ./validate
      
      Reviewers: alexbiehl, hvr, gershomb, harpocrates, bgamari
      
      Reviewed By: alexbiehl
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4758
      85309a3c
  24. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  25. 30 May, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
  26. 20 May, 2018 1 commit
    • patrickdoc's avatar
      Add HeapView functionality · ec22f7dd
      patrickdoc authored
      This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
      The bits added are the C hooks into the RTS and a basic Haskell wrapper
      to these C hooks. The main reason for these to be added to GHC proper
      is that the code needs to be kept in sync with the closure types
      defined by the RTS. It is expected that the version of HeapView shipped
      with GHC will always work with that version of GHC and that extra
      functionality can be layered on top with a library like ghc-heap-view
      distributed via Hackage.
      
      Test Plan: validate
      
      Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3055
      ec22f7dd
  27. 05 May, 2018 1 commit
  28. 19 Apr, 2018 1 commit
  29. 13 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  30. 09 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Bump template-haskell to 2.14.0.0 · 48f55e76
      Ryan Scott authored
      Summary:
      There has been at least one breaking change to
      `template-haskell` (the removal of `qAddForeignFile`) which is
      causing packages like `th-orphans` and `singletons` to fail to build
      with GHC HEAD. Let's bump `template-haskell`'s major version number
      so that these packages can properly guard against these changes.
      
      While I was in town, I also started a `changelog` section for
      the next major version of `template-haskell`, and copied over
      finishing touches for `template-haskell-2.13.0.0`.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4558
      48f55e76
  31. 02 Mar, 2018 1 commit
    • shlevy's avatar
      Make cost centre symbol names deterministic. · d8e47a2e
      shlevy authored
      Previously, non-CAF cost centre symbol names contained a unique,
      leading to non-deterministic object files which, among other issues,
      can lead to an inconsistency causing linking failure when using cached
      builds sourced from multiple machines, such as with nix. Now, each
      cost centre symbol is annotated with the type of cost centre it
      is (CAF, expression annotation, declaration annotation, or HPC) and,
      when a single module has multiple cost centres with the same name and
      type, a 0-based index.
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: niteria, simonmar, RyanGlScott, osa1, rwbarton, thomie, carter
      
      GHC Trac Issues: #4012, #12935
      
      Differential Revision: https://phabricator.haskell.org/D4388
      d8e47a2e
  32. 13 Feb, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Collect CCs in CorePrep, including CCs in unfoldings · 59574058
      Ömer Sinan Ağacan authored
      This patch includes two changes:
      
      1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able
         to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so
         that's the latest stage in the compilation pipeline for this.
      
         After this change `SCCfinal` no longer collects all cost centres, but
         it still generates & collects CAF cost centres + updates cost centre
         stacks of `StgRhsClosure` and `StgRhsCon`s.
      
         This fixes #5889.
      
      2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With
         this we no longer need to update cost centre stack fields in
         `SCCfinal`, so that module is removed.
      
         Cost centre initialization explained in Note [Cost-centre
         initialization plan].
      
         Because with -fcaf-all we need to attach a new cost-centre to each
         CAF, `coreTopBindToStg` now returns `CollectedCCs`.
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, simonmar
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #5889
      
      Differential Revision: https://phabricator.haskell.org/D4325
      59574058
  33. 26 Jan, 2018 2 commits
    • Michal Terepeta's avatar
      Remove Hoopl.Unique · bd58e290
      Michal Terepeta authored
      Reasons to remove:
      - It's confusing - we already have a widely used `Unique` module in
        `basicTypes/` that defines a newtype called `Unique`
      - `Hoopl.Unique` is not actually used much
      
      I've also moved the `Unique{Map,Set}` from `Hoopl.Unique` to
      `Hoopl.Collections` to keep things together. But that module is also a
      bit funny - it defines two type-classes that have only one instance
      each. So we should probably either remove them or use them more
      widely... In any case, that will be a separate change.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: kavon, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4331
      bd58e290
    • Joachim Breitner's avatar
      Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
      Joachim Breitner authored
      Ideally, I'd like to do
      
          type EvTerm = CoreExpr
      
      and the type checker builds the evidence terms as it goes. This failed,
      becuase the evidence for `Typeable` refers to local identifiers that are
      added *after* the typechecker solves constraints. Therefore, `EvTerm`
      stays a data type with two constructors: `EvExpr` for `CoreExpr`
      evidence, and `EvTypeable` for the others.
      
      Delted `Note [Memoising typeOf]`, its reference (and presumably
      relevance) was removed in 8fa4bf9a.
      
      Differential Revision: https://phabricator.haskell.org/D4341
      0e022e56
  34. 23 Nov, 2017 1 commit
  35. 11 Nov, 2017 1 commit
  36. 09 Nov, 2017 1 commit
    • Tamar Christina's avatar
      Update Win32 version for GHC 8.4. · bdd2d286
      Tamar Christina authored
      Update to Win32 2.6 which is the expected version release for 8.4
      
      This involves moving Cabal forward which brings some backwards incompatible
      changes that needs various fixups.
      
      Bump a bunch of submodules
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: angerman, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D4133
      bdd2d286
  37. 29 Oct, 2017 1 commit
    • Joachim Breitner's avatar
      Implement a dedicated exitfication pass #14152 · 0e953da1
      Joachim Breitner authored
      The idea is described in #14152, and can be summarized: Float the exit
      path out of a joinrec, so that the simplifier can do more with it.
      See the test case for a nice example.
      
      The floating goes against what the simplifier usually does, hence we
      need to be careful not inline them back.
      
      The position of exitification in the pipeline was chosen after a small
      amount of experimentation, but may need to be improved. For example,
      exitification can allow rewrite rules to fire, but for that it would
      have to happen before the `simpl_phases`.
      
      Perf.haskell.org reports these nice performance wins:
      
          Nofib allocations
          fannkuch-redux    78446640  - 99.92%      64560
          k-nucleotide     109466384  - 91.32%    9502040
          simple            72424696  -  5.96%   68109560
      
          Nofib instruction counts
          fannkuch-redux  1744331636  -  3.86% 1676999519
          k-nucleotide    2318221965  -  6.30% 2172067260
          scs             1978470869  -  3.35% 1912263779
          simple           669858104  -  3.38%  647206739
          spectral-norm    186423292  -  5.37%  176411536
      
      Differential Revision: https://phabricator.haskell.org/D3903
      0e953da1