1. 22 Jun, 2016 10 commits
    • Simon Peyton Jones's avatar
      Improve error message in deriving( Functor ) · cc92a446
      Simon Peyton Jones authored
      Fixes Trac #12163.  Pretty simple.
      cc92a446
    • Simon Peyton Jones's avatar
      Comments only · 7e7aeab2
      Simon Peyton Jones authored
      7e7aeab2
    • Simon Marlow's avatar
      Accept new (lower) allocations for T7257 · 15641b07
      Simon Marlow authored
      15641b07
    • niteria's avatar
      Make the Ord Module independent of Unique order (2nd try) · 348f2dbb
      niteria authored
      The `Ord Module` instance currently uses `Unique`s for comparison.
      We don't want to use the `Unique` order because it can introduce
      nondeterminism.
      This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic
      ordering making `Ord Module` deterministic transitively.
      
      I've run `nofib` and it doesn't make a measurable difference.
      
      See also Note [ModuleEnv determinism and performance].
      
      This fixes #12191 - the regression, that the previous version of this
      patch had.
      
      Test Plan:
      ./validate
      run nofib: P112
      
      Reviewers: simonmar, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2354
      
      GHC Trac Issues: #4012, #12191
      348f2dbb
    • niteria's avatar
      Don't error on GCC inlining warning in rts · 93f40cb9
      niteria authored
      The warning for reference:
      ```
      rts/RaiseAsync.c: In function ‘throwToMsg’:
      
      rts/SMPClosureOps.h:65:0: error:
           error: inlining failed in call to ‘lockClosure’: call is unlikely
      and code size would grow
      
      rts/RaiseAsync.c:305:0: error:  error: called from here
      
      rts/SMPClosureOps.h:65:0: error:
           error: inlining failed in call to ‘lockClosure’: call is unlikely
      and code size would grow
      ```
      
      This warning triggers on `gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)`
      and it doesn't trigger with new GCCs.
      
      Test Plan: build ghc/rts
      
      Reviewers: bgamari, simonmar, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2353
      93f40cb9
    • Gabor Greif's avatar
      More typos in comments [skip ci] · 61995883
      Gabor Greif authored
      61995883
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 4e7d8350
      Gabor Greif authored
      4e7d8350
    • Simon Marlow's avatar
      9d62d09a
    • Simon Marlow's avatar
      Fix build breakage due to rebase · c0583a9e
      Simon Marlow authored
      c0583a9e
    • Simon Marlow's avatar
      Second attempt to fix sizeExpr · a47b62cb
      Simon Marlow authored
      Summary:
      Background:
      * sizeExpr was calculating expressions like ((e `cast` T) x) wrongly
      * Fixing it caused regressions in compile performance, and one nofib
        program (k-nucleotide)
      
      I managed to fix the source of the compiler regressions.  I think it was
      due to traceTc not being inlined, which I fixed in a more robust way by
      putting an export list on TcRnMonad.
      
      The k-nucleotide regression is more difficult.  I don't think anything
      is actually going wrong, but this program has been highly tuned and is
      quite sensitive to changing in inlining behaviour.  I managed to recover
      most of the performance by manual lambda-lifting which makes it a bit
      less fragile, but the end result was a bit slower.  I don't think this
      is disastrous, the program is pretty horrible to begin with and we could
      probably make a faster one by starting from scratch.
      
      Test Plan: validate, nofib
      
      Reviewers: simonpj, bgamari, niteria, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2338
      
      GHC Trac Issues: #11564
      a47b62cb
  2. 21 Jun, 2016 5 commits
    • niteria's avatar
      Make checkFamInstConsistency less expensive · 12306294
      niteria authored
      Doing canonicalization on every comparison turned
      out to be very expensive.
      
      Caching the canonicalization through the smart `modulePair` constructor
      gives `8%` reduction in allocations on `haddock.compiler` and
      `8.5%` reduction in allocations on `haddock.Cabal`.
      Possibly other things as well, but it's really visible in Haddock.
      
      Test Plan: ./validate
      
      Reviewers: jstolarek, simonpj, austin, simonmar, bgamari
      
      Reviewed By: simonpj, simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2350
      
      GHC Trac Issues: #12191
      12306294
    • Simon Peyton Jones's avatar
      Delete commented-out code · 97a50f82
      Simon Peyton Jones authored
      Richard: in a previous commit I combined the two case for
      
         decideQuantification
      
      This commit just deletes the old code. I'm afraid it'll leave you
      with a merge conflict though, with your stuff on generalisation.
      97a50f82
    • Simon Peyton Jones's avatar
      Don't quantify over Refl in a RULE · d09e982c
      Simon Peyton Jones authored
      This fixes Trac #12212.  It's quite hard to provoke, but I've
      added a standalone test case that does so.
      
      The issue is explained in Note [Evidence foralls] in Specialise.
      d09e982c
    • Gabor Greif's avatar
      Typos in comments · 7301404d
      Gabor Greif authored
      7301404d
    • Simon Marlow's avatar
      ee3bde79
  3. 20 Jun, 2016 21 commits
  4. 18 Jun, 2016 4 commits
    • Ben Gamari's avatar
      llvmGen: Add strictness to metadata fields · 0be38a22
      Ben Gamari authored
      0be38a22
    • Peter Trommler's avatar
      PPC NCG: Fix and refactor TOC handling. · f4b0488d
      Peter Trommler authored
      In a call to a fixed function the TOC does not need to be saved.
      The linker handles TOC saving.
      
      Refactor TOC handling by folding the two functions toc_before and
      toc_after into the code generating the call sequence. This saves
      repeating the case distinction in those two functions.
      
      Test Plan: validate on PowerPC 32-bit Linux and AIX
      
      Reviewers: hvr, simonmar, austin, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2328
      f4b0488d
    • Peter Trommler's avatar
      PPC NCG: Fix float parameter passing on 64-bit. · 2897be77
      Peter Trommler authored
      On Linux 64-bit PowerPC the first 13 floating point parameters are
      passed in registers. We only passed the first 8 floating point params.
      
      The alignment of a floating point single precision value in ELF v1.9 is
      the second word of a doubleword. For ELF v2 we support only little
      endian and the least significant word of a doubleword is the first word,
      so no special handling is required.
      
      Add a regression test.
      
      Test Plan: validate on powerpc Linux and AIX
      
      Reviewers: erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2327
      
      GHC Trac Issues: #12134
      2897be77
    • seraphime's avatar
      Fix trac #10647: Notice about lack of SIMD support · f12fb8ab
      seraphime authored
      Fixes #10647. Changes the error message when a SIMD size
      variable is required in the native code generation backend.
      
      Test Plan:
      Try compiling the test case given in the ticket :
      
      {-# LANGUAGE MagicHash #-}
      module Foo where
      import GHC.Prim
      data V = V Int8X16#
      
      GHC should give a clearer error message
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2325
      
      GHC Trac Issues: #10647
      f12fb8ab