1. 04 Jan, 2020 1 commit
  2. 18 Dec, 2019 1 commit
    • Sylvain Henry's avatar
      Add GHC-API logging hooks · 58655b9d
      Sylvain Henry authored
      * Add 'dumpAction' hook to DynFlags.
      
      It allows GHC API users to catch dumped intermediate codes and
      information. The format of the dump (Core, Stg, raw text, etc.) is now
      reported allowing easier automatic handling.
      
      * Add 'traceAction' hook to DynFlags.
      
      Some dumps go through the trace mechanism (for instance unfoldings that
      have been considered for inlining). This is problematic because:
      1) dumps aren't written into files even with -ddump-to-file on
      2) dumps are written on stdout even with GHC API
      3) in this specific case, dumping depends on unsafe globally stored
      DynFlags which is bad for GHC API users
      
      We introduce 'traceAction' hook which allows GHC API to catch those
      traces and to avoid using globally stored DynFlags.
      
      * Avoid dumping empty logs via dumpAction/traceAction (but still write
      empty files to keep the existing behavior)
      58655b9d
  3. 05 Dec, 2019 1 commit
    • Vladislav Zavialov's avatar
      Pretty-printing of the * kind · 3354c68e
      Vladislav Zavialov authored
      Before this patch, GHC always printed the * kind unparenthesized.
      
      This led to two issues:
      
      1. Sometimes GHC printed invalid or incorrect code.
         For example, GHC would print:  type F @*   x = x
               when it meant to print:  type F @(*) x = x
         In the former case, instead of a kind application we were getting a
         type operator (@*).
      
      2. Sometimes GHC printed kinds that were correct but hard to read.
         Should  Either * Int  be read as  Either (*) Int
                                    or as  (*) Either Int  ?
         This depends on whether -XStarIsType is enabled, but it would be
         easier if we didn't have to check for the flag when reading the code.
      
      We can solve both problems by assigning (*) a different precedence. Note
      that Haskell98 kinds are not affected:
      
        ((* -> *) -> *) -> *  does NOT become  (((*) -> (*)) -> (*)) -> (*)
      
      The parentheses are added when (*) is used in a function argument
      position:
      
         F * * *   becomes  F (*) (*) (*)
         F A * B   becomes  F A (*) B
         Proxy *   becomes  Proxy (*)
         a * -> *  becomes  a (*) -> *
      3354c68e
  4. 02 Dec, 2019 1 commit
  5. 28 Nov, 2019 1 commit
  6. 24 Nov, 2019 1 commit
  7. 10 Nov, 2019 1 commit
    • Richard Eisenberg's avatar
      Fix #17405 by not checking imported equations · 55ca1085
      Richard Eisenberg authored
      Previously, we checked all imported type family equations
      for injectivity. This is very silly. Now, we check only
      for conflicts.
      
      Before I could even imagine doing the fix, I needed to untangle
      several functions that were (in my opinion) overly complicated.
      It's still not quite as perfect as I'd like, but it's good enough
      for now.
      
      Test case: typecheck/should_compile/T17405
      55ca1085
  8. 30 Oct, 2019 1 commit
    • Vladislav Zavialov's avatar
      Whitespace forward compatibility for proposal #229 · 3e7569bc
      Vladislav Zavialov authored
      GHC Proposal #229 changes the lexical rules of Haskell, which may
      require slight whitespace adjustments in certain cases.
      
      This patch changes formatting in a few places in GHC and its testsuite
      in a way that enables it to compile under the proposed rules.
      3e7569bc
  9. 23 Oct, 2019 2 commits
    • Andreas Klebinger's avatar
      Fix bug in the x86 backend involving the CFG. · aa778152
      Andreas Klebinger authored
      This is part two of fixing #17334.
      
      There are two parts to this commit:
      
      - A bugfix for computing loop levels
      - A bugfix of basic block invariants in the NCG.
      
      -----------------------------------------------------------
      
      In the first bug we ended up with a CFG of the sort: [A -> B -> C]
      This was represented via maps as fromList [(A,B),(B,C)] and later
      transformed into a adjacency array. However the transformation did
      not include block C in the array (since we only looked at the keys of
      the map).
      
      This was still fine until we tried to look up successors for C and tried
      to read outside of the array bounds when accessing C.
      
      In order to prevent this in the future I refactored to code to include
      all nodes as keys in the map representation. And make this a invariant
      which is checked in a few places.
      
      Overall I expect this to make the code more robust as now any failed
      lookup will represent an error, versus failed lookups sometimes being
      expected and sometimes not.
      
      In terms of performance this makes some things cheaper (getting a list
      of all nodes) and others more expensive (adding a new edge). Overall
      this adds up to no noteable performance difference.
      
      -----------------------------------------------------------
      
      Part 2: When the NCG generated a new basic block, it did
      not always insert a NEWBLOCK meta instruction in the stream which
      caused a quite subtle bug.
      
          During instruction selection a statement `s`
          in a block B with control of the sort: B -> C
          will sometimes result in control
          flow of the sort:
      
                  ┌ < ┐
                  v   ^
            B ->  B1  ┴ -> C
      
          as is the case for some atomic operations.
      
          Now to keep the CFG in sync when introducing B1 we clearly
          want to insert it between B and C. However there is
          a catch when we have to deal with self loops.
      
          We might start with code and a CFG of these forms:
      
          loop:
              stmt1               ┌ < ┐
              ....                v   ^
              stmtX              loop ┘
              stmtY
              ....
              goto loop:
      
          Now we introduce B1:
                                  ┌ ─ ─ ─ ─ ─┐
              loop:               │   ┌ <  ┐ │
              instrs              v   │    │ ^
              ....               loop ┴ B1 ┴ ┘
              instrsFromX
              stmtY
              goto loop:
      
          This is simple, all outgoing edges from loop now simply
          start from B1 instead and the code generator knows which
          new edges it introduced for the self loop of B1.
      
          Disaster strikes if the statement Y follows the same pattern.
          If we apply the same rule that all outgoing edges change then
          we end up with:
      
              loop ─> B1 ─> B2 ┬─┐
                │      │    └─<┤ │
                │      └───<───┘ │
                └───────<────────┘
      
          This is problematic. The edge B1->B1 is modified as expected.
          However the modification is wrong!
      
          The assembly in this case looked like this:
      
          _loop:
              <instrs>
          _B1:
              ...
              cmpxchgq ...
              jne _B1
              <instrs>
              <end _B1>
          _B2:
              ...
              cmpxchgq ...
              jne _B2
              <instrs>
              jmp loop
      
          There is no edge _B2 -> _B1 here. It's still a self loop onto _B1.
      
          The problem here is that really B1 should be two basic blocks.
          Otherwise we have control flow in the *middle* of a basic block.
          A contradiction!
      
          So to account for this we add yet another basic block marker:
      
          _B:
              <instrs>
          _B1:
              ...
              cmpxchgq ...
              jne _B1
              jmp _B1'
          _B1':
              <instrs>
              <end _B1>
          _B2:
              ...
      
          Now when inserting B2 we will only look at the outgoing edges of B1' and
          everything will work out nicely.
      
          You might also wonder why we don't insert jumps at the end of _B1'. There is
          no way another block ends up jumping to the labels _B1 or _B2 since they are
          essentially invisible to other blocks. View them as control flow labels local
          to the basic block if you'd like.
      
          Not doing this ultimately caused (part 2 of) #17334.
      aa778152
    • Richard Eisenberg's avatar
      Implement a coverage checker for injectivity · 1cd3fa29
      Richard Eisenberg authored
      This fixes #16512.
      
      There are lots of parts of this patch:
      
      * The main payload is in FamInst. See
      Note [Coverage condition for injective type families] there
      for the overview. But it doesn't fix the bug.
      
      * We now bump the reduction depth every time we discharge
      a CFunEqCan. See Note [Flatten when discharging CFunEqCan]
      in TcInteract.
      
      * Exploration of this revealed a new, easy to maintain invariant
      for CTyEqCans. See Note [Almost function-free] in TcRnTypes.
      
      * We also realized that type inference for injectivity was a
      bit incomplete. This means we exchanged lookupFlattenTyVar for
      rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new
      function is monadic while the previous one was pure, necessitating
      some faff in TcInteract. Nothing too bad.
      
      * zonkCt did not maintain invariants on CTyEqCan. It's not worth
      the bother doing so, so we just transmute CTyEqCans to
      CNonCanonicals.
      
      * The pure unifier was finding the fixpoint of the returned
      substitution, even when doing one-way matching (in tcUnifyTysWithTFs).
      Fixed now.
      
      Test cases: typecheck/should_fail/T16512{a,b}
      1cd3fa29
  10. 16 Oct, 2019 1 commit
    • Andreas Klebinger's avatar
      Add loop level analysis to the NCG backend. · 535a88e1
      Andreas Klebinger authored
      For backends maintaining the CFG during codegen
      we can now find loops and their nesting level.
      
      This is based on the Cmm CFG and dominator analysis.
      
      As a result we can estimate edge frequencies a lot better
      for methods, resulting in far better code layout.
      
      Speedup on nofib: ~1.5%
      Increase in compile times: ~1.9%
      
      To make this feasible this commit adds:
      * Dominator analysis based on the Lengauer-Tarjan Algorithm.
      * An algorithm estimating global edge frequences from branch
      probabilities - In CFG.hs
      
      A few static branch prediction heuristics:
      
      * Expect to take the backedge in loops.
      * Expect to take the branch NOT exiting a loop.
      * Expect integer vs constant comparisons to be false.
      
      We also treat heap/stack checks special for branch prediction
      to avoid them being treated as loops.
      535a88e1
  11. 09 Oct, 2019 1 commit
  12. 05 Oct, 2019 1 commit
    • John Ericson's avatar
      Clean up `#include`s in the compiler · ee8118ca
      John Ericson authored
       - Remove unneeded ones
      
       - Use <..> for inter-package.
         Besides general clean up, helps distinguish between the RTS we link
         against vs the RTS we compile for.
      ee8118ca
  13. 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
  14. 21 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      PredType for type constraints in the pattern match checker instead of EvVar · 1ea8c451
      Sebastian Graf authored
      Using EvVars for capturing type constraints implied side-effects in DsM
      when we just wanted to *construct* type constraints.
      
      But giving names to type constraints is only necessary when passing
      Givens to the type checker, of which the majority of the pattern match
      checker should be unaware.
      
      Thus, we simply generate `newtype TyCt = TyCt PredType`, which are
      nicely stateless. But at the same time this means we have to allocate
      EvVars when we want to query the type oracle! So we keep the type oracle
      state as `newtype TyState = TySt (Bag EvVar)`, which nicely makes a
      distinction between new, unchecked `TyCt`s and the inert set in
      `TyState`.
      1ea8c451
  15. 16 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      Encode shape information in `PmOracle` · 7915afc6
      Sebastian Graf authored
      Previously, we had an elaborate mechanism for selecting the warnings to
      generate in the presence of different `COMPLETE` matching groups that,
      albeit finely-tuned, produced wrong results from an end user's
      perspective in some cases (#13363).
      
      The underlying issue is that at the point where the `ConVar` case has to
      commit to a particular `COMPLETE` group, there's not enough information
      to do so and the status quo was to just enumerate all possible complete
      sets nondeterministically.  The `getResult` function would then pick the
      outcome according to metrics defined in accordance to the user's guide.
      But crucially, it lacked knowledge about the order in which affected
      clauses appear, leading to the surprising behavior in #13363.
      
      In !1010 we taught the term oracle to reason about literal values a
      variable can certainly not take on. This MR extends that idea to
      `ConLike`s and thereby fixes #13363: Instead of committing to a
      particular `COMPLETE` group in the `ConVar` case, we now split off the
      matching constructor incrementally and record the newly covered case as
      a refutable shape in the oracle. Whenever the set of refutable shapes
      covers any `COMPLETE` set, the oracle recognises vacuosity of the
      uncovered set.
      
      This patch goes a step further: Since at this point the information
      in value abstractions is merely a cut down representation of what the
      oracle knows, value abstractions degenerate to a single `Id`, the
      semantics of which is determined by the oracle state `Delta`.
      Value vectors become lists of `[Id]` given meaning to by a single
      `Delta`, value set abstractions (of which the uncovered set is an
      instance) correspond to a union of `Delta`s which instantiate the
      same `[Id]` (akin to models of formula).
      
      Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149
      
      -------------------------
      Metric Decrease:
          ManyAlternatives
          T11195
      -------------------------
      7915afc6
  16. 13 Sep, 2019 1 commit
  17. 11 Sep, 2019 1 commit
  18. 09 Sep, 2019 3 commits
    • Daniel Gröber (dxld)'s avatar
      Update FastString docstrings · f5e2fde4
      Daniel Gröber (dxld) authored
      1) FastStrings are always UTF-8 encoded now.
      2) Clarify what is meant by "hashed"
      3) Add mention of lazy z-enc
      f5e2fde4
    • 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
    • Moritz Kiefer's avatar
      Fix GHC version guard for Int32Rep/Word32Rep · d0b45ac6
      Moritz Kiefer authored
      Those constructors have been added after GHC 8.8. The version guards
      in `binary` are correct, see https://github.com/kolmodin/binary/pull/167/files.
      d0b45ac6
  19. 28 Aug, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Return results of Cmm streams in backends · 1c7ec449
      Ömer Sinan Ağacan authored
      This generalizes code generators (outputAsm, outputLlvm, outputC, and
      the call site codeOutput) so that they'll return the return values of
      the passed Cmm streams.
      
      This allows accumulating data during Cmm generation and returning it to
      the call site in HscMain.
      
      Previously the Cmm streams were assumed to return (), so the code
      generators returned () as well.
      
      This change is required by !1304 and !1530.
      
      Skipping CI as this was tested before and I only updated the commit
      message.
      
      [skip ci]
      1c7ec449
  20. 23 Aug, 2019 2 commits
    • Andreas Klebinger's avatar
      Use variable length encoding for Binary instances. · 47070144
      Andreas Klebinger authored
      Use LEB128 encoding for Int/Word variants. This reduces
      the size of interface files significantly. (~19%).
      
      Also includes a few small optimizations to make unboxing
      work better that I have noticed while looking at the core.
      47070144
    • Ömer Sinan Ağacan's avatar
      Make non-streaming LLVM and C backends streaming · a8300520
      Ömer Sinan Ağacan authored
      This adds a Stream.consume function, uses it in LLVM and C code
      generators, and removes the use of Stream.collect function which was
      used to collect streaming Cmm generation results into a list.
      
      LLVM and C backends now properly use streamed Cmm generation, instead of
      collecting Cmm groups into a list before generating LLVM/C code.
      a8300520
  21. 19 Aug, 2019 4 commits
  22. 18 Aug, 2019 1 commit
    • Sylvain Henry's avatar
      Faster exactLog2 · ac73c1b1
      Sylvain Henry authored
      Make `exactLog2` faster (use `countLeadingZeros` and Int32 bit-ops).
      
      On my Core i7-9700k Criterion reports ~50% speedup (from 16 to 8ns).
      ac73c1b1
  23. 14 Aug, 2019 1 commit
    • Andreas Klebinger's avatar
      Rework the Binary Integer instance. · a38104b4
      Andreas Klebinger authored
      We used to serialise large integers as strings. Now they are serialized
      as a list of Bytes.
      
      This changes the size for a Integer in the higher 64bit range from 77 to
      9 bytes when written to disk.
      
      The impact on the general case is small (<1% for interface files) as we
      don't use many Integers. But for code that uses many this should be a
      nice benefit.
      a38104b4
  24. 13 Aug, 2019 1 commit
  25. 19 Jul, 2019 1 commit
  26. 17 Jul, 2019 1 commit
    • John Ericson's avatar
      Create {Int,Word}32Rep · 0a9b77b8
      John Ericson authored
      This prepares the way for making Int32# and Word32# the actual size they
      claim to be.
      
      Updates binary submodule for (de)serializing the new runtime reps.
      0a9b77b8
  27. 14 Jul, 2019 1 commit
    • John Ericson's avatar
      Expunge #ifdef and #ifndef from the codebase · d7c6c471
      John Ericson authored
      These are unexploded minds as far as the linter is concerned. I don't
      want to hit in my MRs by mistake!
      
      I did this with `sed`, and then rolled back some changes in the docs,
      config.guess, and the linter itself.
      d7c6c471
  28. 11 Jul, 2019 1 commit
  29. 20 Jun, 2019 2 commits
  30. 16 Jun, 2019 1 commit
  31. 14 Jun, 2019 1 commit
  32. 12 Jun, 2019 1 commit