1. 19 Mar, 2018 9 commits
    • Michal Terepeta's avatar
      Hoopl: improve postorder calculation · bbcea13a
      Michal Terepeta authored
      - Fix the naming and comments to indicate that we are calculating
        *reverse* postorder (and not the standard postorder).
      - Rewrite the calculation to avoid CPS code. I found it fairly
        difficult to understand and the new one seems faster (according to
        nofib, decreases compiler allocations by 0.2%)
      - Remove `LabelsPtr`, which seems unnecessary and could be *really*
        confusing. For instance, previously:
        `postorder_dfs_from <block with label X>`
        `postorder_dfs_from <label X>`
        would actually mean quite different things (and give different
      - Change the `Dataflow` module to always use entry of the graph for
        reverse postorder calculation. This should be the only change in
        behavior of this commit.
        Previously, if the caller provided initial facts for some of the
        labels, we would use those labels for our postorder calculation.
        However, I don't think that's correct in general - if the initial
        facts did not contain the entry of the graph, we would never analyze
        the blocks reachable from the entry but unreachable from the labels
        provided with the initial facts. It seems that the only analysis that
        used this was proc-point analysis, which I think would always include
        the entry block (so I don't think there's any bug due to this).
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      Test Plan: ./validate
      Reviewers: bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4464
    • Michal Terepeta's avatar
      Get rid of more CPP in cmm/ and codeGen/ · 0db0e46c
      Michal Terepeta authored
      This removes a bunch of unnecessary includes of `HsVersions.h` along
      with unnecessary CPP (e.g., due to checking for DEBUG which can be
      achieved by looking at `debugIsOn`)
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      Test Plan: ./validate
      Reviewers: bgamari, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4462
    • Tao He's avatar
      Improve the warning message of qualified unused imports. · fad822e2
      Tao He authored
      Pretty-print unused imported names unqualified unconditionally to
      make the warning message consistent for ambiguous/unambiguous
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      Test Plan: make test TEST="T14881"
      Reviewers: bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, thomie, carter
      GHC Trac Issues: #14881
      Differential Revision: https://phabricator.haskell.org/D4461
    • Simon Marlow's avatar
      Be more selective in which conditionals we invert · 39c74063
      Simon Marlow authored
      Test Plan: validate
      Reviewers: bgamari, AndreasK, erikd
      Reviewed By: AndreasK
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4398
    • Matthew Pickering's avatar
      Also check local rules with -frules-check · 3d378d98
      Matthew Pickering authored
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4255
    • Douglas Wilson's avatar
      rts: Add --internal-counters RTS flag and several counters · 2918abf7
      Douglas Wilson authored
      The existing internal counters:
      * gc_alloc_block_sync
      * whitehole_spin
      * gen[g].sync
      * gen[1].sync
      are now not shown in the -s report unless --internal-counters is also passed.
      If --internal-counters is passed we now show the counters above, reformatted, as
      well as several other counters. In particular, we now count the yieldThread()
      calls that SpinLocks do as well as their spins.
      The added counters are:
      * gc_spin (spin and yield)
      * mut_spin (spin and yield)
      * whitehole_threadPaused (spin only)
      * whitehole_executeMessage (spin only)
      * whitehole_lockClosure (spin only)
      * waitForGcThreadsd (spin and yield)
      As well as the following, which are not SpinLock-like things:
      * any_work
      * do_work
      * scav_find_work
      See the Note for descriptions of what these counters are.
      We add busy_wait_nops in these loops along with the counter increment where it
      was absent.
      Old internal counters output:
      gc_alloc_block_sync: 0
      whitehole_gc_spin: 0
      gen[0].sync: 0
    • Mark Karpov's avatar
      Add a build with 32bit Ubuntu container · f9a6d420
      Mark Karpov authored
    • Ömer Sinan Ağacan's avatar
      Update test for #5129: · 5a1ad231
      Ömer Sinan Ağacan authored
      Make sure it runs with --fast validate with correct optimisation
      settings (-O1 or above) so that it actually tests the bug.
      Because the bug is in the simplifier running it with -O0 doesn't
      test it.
    • Simon Peyton Jones's avatar
      Comments and tiny refactor · 2a3702d8
      Simon Peyton Jones authored
      Related to Ryan's upcoming patch for Trac #14933
  2. 17 Mar, 2018 2 commits
    • Sergei Trofimovich's avatar
      aclocal.m4: add OSHurd (debian patch) · 0693b0b0
      Sergei Trofimovich authored
      ghc treats OSUnknown (and GNU/Hurd) as non-ELF target.
      This causes panic in native codegenerator when trying
      to build PIC code:
        -- all other platforms
        howToAccessLabel dflags _ _ _ _ _
              | not (positionIndependent dflags)
              = AccessDirectly
              | otherwise
              = panic "howToAccessLabel: PIC not defined for this platform"
      This change declares new 'OSHurd' and marks it as an
      ELF target. Fixes building ghc-stage2 on i686-unknown-gnu0.9.
      Patch provided by "Pino" via Samuel Thibault and taken from
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
    • Sergei Trofimovich's avatar
      aclocal.m4: allow more GNU/Hurd tuples · 1522cf05
      Sergei Trofimovich authored
      Running plain ./configure fails on hurd because
      ./config.guess reports unrecognised tuple:
          $ ./config.guess
      The change makes the following target configure:
      $ ./configure --target=i686-unknown-gnu0.9
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
  3. 14 Mar, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Slighly improve infix con app pattern errors · cb6d8589
      Ömer Sinan Ağacan authored
      Given this program:
          main = do
            f $ do
              a <- return 3
                c <- do
                return 5
      GHC previously gave this error message:
          Main.hs:2:7: error:
              Parse error in pattern: do a <- return 3 c
              Possibly caused by a missing 'do'?
          2 |   f $ do
            |       ^^...
      What happened is GHC considered the whole `f $ do a <- return 3 c` as a
      pattern. When parsed as an expression it becomes an infix application of
      `($)`, and GHC checks left and right hand sides before checking if `($)`
      is a valid infix constructor name, and shows the first error it got.
      If instead we first check if the infix op is valid in pattern context,
      the error message becomes much clearer:
          Main.hs:2:3: error:
              Parse error in pattern: f $ do a <- return 3 c
              Possibly caused by a missing 'do'?
          2 |   f $ do
            |   ^^^^^^...
      This may not entirely fix #11188 but I think it's an improvement.
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #11188
      Differential Revision: https://phabricator.haskell.org/D4497
  4. 13 Mar, 2018 3 commits
  5. 12 Mar, 2018 2 commits
  6. 10 Mar, 2018 2 commits
  7. 09 Mar, 2018 2 commits
  8. 08 Mar, 2018 11 commits
  9. 07 Mar, 2018 3 commits
  10. 06 Mar, 2018 5 commits