1. 23 Oct, 2019 13 commits
    • Andreas Klebinger's avatar
      Make dynflag argument for withTiming pure. · 6beea836
      Andreas Klebinger authored
      19 times out of 20 we already have dynflags in scope.
      
      We could just always use `return dflags`. But this is in fact not free.
      When looking at some STG code I noticed that we always allocate a
      closure for this expression in the heap. Clearly a waste in these cases.
      
      For the other cases we can either just modify the callsite to
      get dynflags or use the _D variants of withTiming I added which
      will use getDynFlags under the hood.
      6beea836
    • Ben Gamari's avatar
      Bump stm submodule · 9c1f0f7c
      Ben Gamari authored
      9c1f0f7c
    • ryates@cs.rochester.edu's avatar
      Full abort on validate failure merging `orElse`. · 1f40e68a
      ryates@cs.rochester.edu authored
      Previously partial roll back of a branch of an `orElse` was attempted
      if validation failure was observed.  Validation here, however, does
      not account for what part of the transaction observed inconsistent
      state.  This commit fixes this by fully aborting and restarting the
      transaction.
      1f40e68a
    • 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
    • Takenobu Tani's avatar
      Allow command name resolution for GHCi commands with option `!` #17345 · 4798f3b9
      Takenobu Tani authored
      This commit allows command name resolution for GHCi commands
      with option `!` as follows:
      
          ghci> :k! Int
          Int :: *
          = Int
      
      This commit changes implementation as follows:
      
      Before:
        * Prefix match with full string including the option `!` (e.g. `k!`)
      
      After (this patch):
        * Prefix match without option suffix `!` (e.g. `k`)
        * in addition, suffix match with option `!`
      
      See also #8305 and #8113
      4798f3b9
    • Matthew Pickering's avatar
      eventlog: Dump cost centre stack on each sample · 17987a4b
      Matthew Pickering authored
      With this change it is possible to reconstruct the timing portion of a
      `.prof` file after the fact. By logging the stacks at each time point
      a more precise executation trace of the program can be observed rather
      than all identical cost centres being identified in the report.
      
      There are two new events:
      
      1. `EVENT_PROF_BEGIN` - emitted at the start of profiling to communicate
      the tick interval
      2. `EVENT_PROF_SAMPLE_COST_CENTRE` - emitted on each tick to communicate the
      current call stack.
      
      Fixes #17322
      17987a4b
    • Ömer Sinan Ağacan's avatar
      Refactor Compact.c: · b521e8b6
      Ömer Sinan Ağacan authored
      - Remove forward declarations
      - Introduce UNTAG_PTR and GET_PTR_TAG for dealing with pointer tags
        without having to cast arguments to StgClosure*
      - Remove dead code
      - Use W_ instead of StgWord
      - Use P_ instead of StgPtr
      b521e8b6
    • Ben Gamari's avatar
      testsuite: Don't run T7653 in ghci and profiled ways · 9b2a5008
      Ben Gamari authored
      Currently this routinely fails in the i386 job.
      See #7653.
      9b2a5008
    • Ryan Scott's avatar
      Reify oversaturated data family instances correctly (#17296) · a19c7d17
      Ryan Scott authored
      `TcSplice` was not properly handling oversaturated data family
      instances, such as the example in #17296, as it dropped arguments due
      to carelessly zipping data family instance arguments with
      `tyConTyVars`. For data families, the number of `tyConTyVars` can
      sometimes be less than the number of arguments it can accept in a
      data family instance due to the fact that data family instances can
      be oversaturated.
      
      To account for this, `TcSplice.mkIsPolyTvs` has now been renamed to
      `tyConArgsPolyKinded` and now factors in `tyConResKind` in addition
      to `tyConTyVars`. I've also added
      `Note [Reified instances and explicit kind signatures]` which
      explains the various subtleties in play here.
      
      Fixes #17296.
      a19c7d17
    • Alp Mestanogullari's avatar
      compiler: introduce DynFlags plugins · 900cf195
      Alp Mestanogullari authored
      They have type '[CommandLineOpts] -> Maybe (DynFlags -> IO DynFlags)'.
      All plugins that supply a non-Nothing 'dynflagsPlugin' will see their
      updates applied to the current DynFlags right after the plugins are
      loaded.
      
      One use case for this is to superseede !1580 for registering hooks
      from a plugin. Frontend/parser plugins were considered to achieve this
      but they respectively conflict with how this plugin is going to be used
      and don't allow overriding/modifying the DynFlags, which is how hooks have
      to be registered.
      
      This commit comes with a test, 'test-hook-plugin', that registers a "fake"
      meta hook that replaces TH expressions with the 0 integer literal.
      900cf195
    • 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
    • Andreas Klebinger's avatar
      Warn about missing profiled libs when using the Interpreter. · faa30dcb
      Andreas Klebinger authored
      When GHC itself, or it's interpreter is profiled we need to load
      profiled libraries as well.
      
      This requirement is not always obvious, especially when TH
      implicilty uses the interpreter.
      
      When the libs were not found we fall back to assuming the
      are in a DLL. This is usually not the case so now we warn
      users when we do so. This makes it more obvious what is
      happening and gives users a way to fix the issue.
      
      This fixes #17121.
      faa30dcb
    • David Feuer's avatar
      Use an IORef for QSemN · 96c5411a
      David Feuer authored
      Replace the outer `MVar` in `QSemN` with an `IORef`. This should
      probably be lighter, and it removes the need for `uninterruptibleMask`.
      
      Previously Differential Revision https://phabricator.haskell.org/D4896
      96c5411a
  2. 22 Oct, 2019 4 commits
  3. 20 Oct, 2019 1 commit
  4. 17 Oct, 2019 3 commits
    • Ben Gamari's avatar
      testsuite: Assert that testsuite ways are known · c4c9904b
      Ben Gamari authored
      This ensures that all testsuite way names given to `omit_ways`,
      `only_ways`, etc. are known ways.
      c4c9904b
    • Richard Eisenberg's avatar
      4efdda90
    • Ben Gamari's avatar
      testsuite: Ensure that makefile tests get run · b15a7fb8
      Ben Gamari authored
      Previously `makefile_test` and `run_command` tests could easily end up
      in a situation where they wouldn't be run if the user used the
      `only_ways` modifier. The reason is to build the set of a ways to run
      the test in we first start with a candidate set determined by the test
      type (e.g. `makefile_test`, `compile_run`, etc.) and then filter that
      set with the constraints given by the test's modifiers.
      
      `makefile_test` and `run_command` tests' candidate sets were simply
      `{normal}`, and consequently most uses of `only_ways` would result in
      the test being never run.
      
      To avoid this we rather use all ways as the candidate sets for these
      test types. This may result in a few more testcases than we would like
      (given that some `run_command` tests are insensitive to way) but this
      can be fixed by adding modifiers and we would much rather run too many
      tests than too few.
      
      This fixes #16042 and a number of other tests afflicted by the same issue.
      However, there were a few cases that required special attention:
      
       * `T14028` is currently failing and is therefore marked as broken due
         to #17300
      
       * `T-signals-child` is fragile in the `threaded1` and `threaded2` ways
         (tracked in #17307)
      b15a7fb8
  5. 16 Oct, 2019 9 commits
    • Brian Wignall's avatar
      42ebc3f6
    • Ryan Scott's avatar
      Make Coverage.TM a newtype · deb96399
      Ryan Scott authored
      deb96399
    • Ben Gamari's avatar
      hadrian: Introduce enableDebugInfo flavour transformer · 11d4fc50
      Ben Gamari authored
      Also refactor things a bit to eliminate repetition.
      11d4fc50
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
      
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
      
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
      
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      
      No work other than module splitting is in this patch.
      
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
      51fad9e6
    • John Ericson's avatar
      Delete ghctags cabal file · 798037a1
      John Ericson authored
      It came back to life in 381c3ae3 by
      mistake.
      798037a1
    • Sebastian Graf's avatar
      Infer rho-types instead of sigma-types in guard BindStmts and TransStmts · 6ede3554
      Sebastian Graf authored
      In #17343 we saw that we didn't handle the pattern guard `!_ <-
      undefined` correctly: The `undefined` was never evaluated. Indeed,
      elaboration failed to insert the invisible type aruments to `undefined`.
      So `undefined` was trivially a normal-form and in turn never entered.
      
      The problem is that we used to infer a sigma-type for the RHS of the
      guard, the leading qualifiers of which will never be useful in a pattern
      match situation. Hence we infer a rho-type now.
      
      Fixes #17343.
      6ede3554
    • Takenobu Tani's avatar
      testsuite: Add test for #8305 · 19641957
      Takenobu Tani authored
      This is a test for the current algorithm of GHCi command name resolution.
      
      I add this test in preparation for updating GHCi command name resolution.
      
      For the current algorithm, see https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ghci.html#the-ghci-files
      19641957
    • Adithya Kumar's avatar
    • 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
  6. 15 Oct, 2019 4 commits
    • Ben Gamari's avatar
      9c11f817
    • Alp Mestanogullari's avatar
      a55b8a65
    • Ryan Scott's avatar
      Don't skip validity checks for built-in classes (#17355) · 426b0ddc
      Ryan Scott authored
      Issue #17355 occurred because the control flow for
      `TcValidity.check_valid_inst_head` was structured in such a way that
      whenever it checked a special, built-in class (like `Generic` or
      `HasField`), it would skip the most important check of all:
      `checkValidTypePats`, which rejects nonsense like this:
      
      ```hs
      instance Generic (forall a. a)
      ```
      
      This fixes the issue by carving out `checkValidTypePats` from
      `check_valid_inst_head` so that `checkValidTypePats` is always
      invoked. `check_valid_inst_head` has also been renamed to
      `check_special_inst_head` to reflect its new purpose of _only_
      checking for instances headed by special classes.
      
      Fixes #17355.
      426b0ddc
    • Ryan Scott's avatar
      Refactor some cruft in TcDerivInfer.inferConstraints · a2d3594c
      Ryan Scott authored
      The latest installment in my quest to clean up the code in
      `TcDeriv*`. This time, my sights are set on
      `TcDerivInfer.inferConstraints`, which infers the context for derived
      instances. This function is a wee bit awkward at the moment:
      
      * It's not terribly obvious from a quick glance, but
        `inferConstraints` is only ever invoked when using the `stock` or
        `anyclass` deriving strategies, as the code for inferring the
        context for `newtype`- or `via`-derived instances is located
        separately in `mk_coerce_based_eqn`. But there's no good reason
        for things to be this way, so I moved this code from
        `mk_coerce_based_eqn` to `inferConstraints` so that everything
        related to inferring instance contexts is located in one place.
      * In this process, I discovered that the Haddocks for the auxiliary
        function `inferConstraintsDataConArgs` are completely wrong. It
        claims that it handles both `stock` and `newtype` deriving, but
        this is completely wrong, as discussed above—it only handles
        `stock`. To rectify this, I renamed this function to
        `inferConstraintsStock` to reflect its actual purpose and created
        a new `inferConstraintsCoerceBased` function to specifically
        handle `newtype` (and `via`) deriving.
      
      Doing this revealed some opportunities for further simplification:
      
      * Removing the context-inference–related code from
        `mk_coerce_based_eqn` made me realize that the overall structure
        of the function is basically identical to `mk_originative_eqn`.
        In fact, I was easily able to combine the two functions into a
        single `mk_eqn_from_mechanism` function.
      
        As part of this merger, I now invoke
        `atf_coerce_based_error_checks` from `doDerivInstErrorChecks1`.
      * I discovered that GHC defined this function:
      
        ```hs
        typeToTypeKind = liftedTypeKind `mkVisFunTy` liftedTypeKind
        ```
      
        No fewer than four times in different modules. I consolidated all
        of these definitions in a single location in `TysWiredIn`.
      a2d3594c
  7. 14 Oct, 2019 3 commits
    • Ben Gamari's avatar
      gitlab-ci: Move hadrian-ghc-in-ghci job first · 0ca044fd
      Ben Gamari authored
      This is a very cheap job and can catch a number of "easy" failure modes
      (e.g. missing imports in the compiler). Let's run it first.
      0ca044fd
    • Ryan Scott's avatar
      Mention changes from #16980, #17213 in 8.10.1 release notes · 4aba72d6
      Ryan Scott authored
      The fixes for these issues both have user-facing consequences, so it
      would be good to mention them in the release notes for GHC 8.10.1.
      
      While I'm in town, also mention `UnboxedSums` in the release notes
      entry related to `-fobject-code`.
      4aba72d6
    • Ryan Scott's avatar
      Add docs/users_guide/.log to .gitignore · 78463fc5
      Ryan Scott authored
      When the users guide fails to build (as in #17346), a
      `docs/users_guide/.log` file will be generated with contents that
      look something like this:
      
      ```
      WARNING: unknown config value 'latex_paper_size' in override, ignoring
      /home/rgscott/Software/ghc5/docs/users_guide/ghci.rst:3410: WARNING: u'ghc-flag' reference target not found: -pgmo ?option?
      /home/rgscott/Software/ghc5/docs/users_guide/ghci.rst:3410: WARNING: u'ghc-flag' reference target not found: -pgmo ?port?
      
      Encoding error:
      'ascii' codec can't encode character u'\u27e8' in position 132: ordinal not in range(128)
      The full traceback has been saved in /tmp/sphinx-err-rDF2LX.log, if you want to report the issue to the developers.
      ```
      
      This definitely should not be checked in to version control, so let's
      add this to `.gitignore`.
      78463fc5
  8. 13 Oct, 2019 3 commits