1. 28 Nov, 2019 1 commit
  2. 16 Aug, 2019 1 commit
  3. 07 Aug, 2019 1 commit
  4. 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.
  5. 08 Mar, 2019 1 commit
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      Ticket #14741 can be fixed if the original code uses this new TH feature.
  6. 15 Feb, 2019 1 commit
    • Alec Theriault's avatar
      Properly escape character literals in Haddocks · 173d0cee
      Alec Theriault authored
      Character literals in Haddock should not be written as plain `'\n'` since
      single quotes are for linking identifiers. Besides, since we want the
      character literal to be monospaced, we really should use `@\'\\n\'@`.
      [skip ci]
  7. 31 Jan, 2019 1 commit
  8. 22 Nov, 2018 1 commit
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      Subscribers: tdammers, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4881
  9. 14 Oct, 2018 1 commit
    • Sebastian Graf's avatar
      Add RubbishLit for absent bindings of UnliftedRep · 448b77b9
      Sebastian Graf authored
      Trac #9279 reminded us that the worker wrapper transformation copes
      really badly with absent unlifted boxed bindings.
      As `Note [Absent errors]` in WwLib.hs points out, we can't just use
      `absentError` for unlifted bindings because there is no bottom to hide
      the error in.
      So instead, we synthesise a new `RubbishLit` of type
      `forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for
      any boxed value. We choose `()`, so that there is a good chance that
      the program crashes instead instead of leading to corrupt data, should
      absence analysis have been too optimistic (#11126).
      Reviewers: simonpj, hvr, goldfire, bgamari, simonmar
      Reviewed By: simonpj
      Subscribers: osa1, rwbarton, carter
      GHC Trac Issues: #15627, #9279, #4306, #11126
      Differential Revision: https://phabricator.haskell.org/D5153
  10. 15 Jun, 2018 1 commit
    • Sylvain Henry's avatar
      Built-in Natural literals in Core · fe770c21
      Sylvain Henry authored
      Add support for built-in Natural literals in Core.
      - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
        constructor with a LitNumType field
      - Support built-in Natural literals
      - Add desugar warning for negative literals
      - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
      This patch introduces only a few rules for Natural literals (compared
      to Integer's rules). Factorization of the built-in rules for numeric
      literals will be done in another patch as this one is already big to
      Test Plan:
        test build with integer-simple
      Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
      Reviewed By: bgamari
      Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
      GHC Trac Issues: #14170, #14465
      Differential Revision: https://phabricator.haskell.org/D4212
  11. 15 May, 2018 1 commit
    • Sebastian Graf's avatar
      Algebraically simplify add/sub with carry/overflow · bb338f2e
      Sebastian Graf authored
      Previously, the `{add,sub}{Int,Word}C#` PrimOps weren't handled
      in PrelRules (constant folding and algebraic simplification) at all.
      This implements the necessary logic, so that using these primitives
      isn't too punishing compared to their well-optimised, overflow-unaware
      This is so that using these primitives in `enumFromThenTo @Int` can
      be optimized by constant folding, reducing closure sizes.
      Reviewers: bgamari, simonpj, hsyl20
      Reviewed By: bgamari, simonpj
      Subscribers: AndreasK, thomie, carter
      GHC Trac Issues: #8763
      Differential Revision: https://phabricator.haskell.org/D4605
  12. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      Reviewed By: bgamari
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      Differential Revision: https://phabricator.haskell.org/D3989
  13. 07 Sep, 2017 1 commit
  14. 28 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer caseRules to add tagToEnum/dataToTag · 193664d4
      Simon Peyton Jones authored
      See Note [Scrutinee Constant Folding] in SimplUtils
      * Add cases for tagToEnum and dataToTag. This is the main new
        bit.  It allows the simplifier to remove the pervasive uses
        of     case tagToEnum (a > b) of
                  False -> e1
                  True  -> e2
        and replace it by the simpler
               case a > b of
                  DEFAULT -> e1
                  1#      -> e2
        See Note [caseRules for tagToEnum]
        and Note [caseRules for dataToTag] in PrelRules.
      * This required some changes to the API of caseRules, and hence
        to code in SimplUtils.  See Note [Scrutinee Constant Folding]
        in SimplUtils.
      * Avoid duplication of work in the (unusual) case of
           case BIG + 3# of b
             DEFAULT -> e1
             6#      -> e2
        Previously we got
           case BIG of
             DEFAULT -> let b = BIG + 3# in e1
             3#      -> let b = 6#       in e2
        Now we get
           case BIG of b#
             DEFAULT -> let b = b' + 3# in e1
             3#      -> let b = 6#      in e2
      * Avoid duplicated code in caseRules
      A knock-on refactoring:
      * Move Note [Word/Int underflow/overflow] to Literal, as
        documentation to accompany mkMachIntWrap etc; and get
        rid of PrelRuls.intResult' in favour of mkMachIntWrap
  15. 26 Feb, 2017 1 commit
    • Joachim Breitner's avatar
      Ensure that Literals are in range · 6dfc5ebf
      Joachim Breitner authored
      This commit fixes several bugs related to case expressions
      involving numeric literals which are not in the range of values of
      their (fixed-width, integral) type.
      There is a new invariant on Literal: The argument of a MachInt[64]
      or MachWord[64] must lie within the range of the corresponding
      primitive type Int[64]# or Word[64]#, as defined by the target machine.
      This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping
      the argument to the target type's range if necessary.
      Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245
      Trac issues: #9533, #10245, #10246, #13171
      Reviewers: simonmar, simonpj, austin, bgamari, nomeata
      Reviewed By: bgamari
      Subscribers: thomie, rwbarton
      Differential Revision: https://phabricator.haskell.org/D810
  16. 09 Dec, 2016 1 commit
    • Sylvain Henry's avatar
      Scrutinee Constant Folding · d3b546b1
      Sylvain Henry authored
      This patch introduces new rules to perform constant folding through
      case t -# 10# of _ {  ===> case t of _ {
               5#      -> e1              15#     -> e1
               8#      -> e2              18#     -> e2
               DEFAULT -> e               DEFAULT -> e
      The initial motivation is that it allows "Merge Nested Cases"
      optimization to kick in and to further simplify the code
      (see Trac #12877).
      Currently we recognize the following operations for Word# and Int#: Add,
      Sub, Xor, Not and Negate (for Int# only).
      Test Plan: validate
      Reviewers: simonpj, austin, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2762
      GHC Trac Issues: #12877
  17. 03 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Merge cpe_ExprIsTrivial and exprIsTrivial · 967dd5c9
      Ben Gamari authored
      Strangely my previous attempts at resolving this all seemed to end in
      perplexing segmentation faults in the GHC testsuite (including some
      rather recent attempts). Somehow this attempt miraculously works.
      However, there was one wrinkle that I still need to work out fully: we
      need to consider Lits as non-trivial in cpeArg. Failure to do this means
      that we would transform something like,
          $trModule = TrModule "HelloWorld"#
          $trModule = case "HelloWorld"# of x { __DEFAULT -> TrModule x }
      Which then fails the consistentStgInfo check in CoreToStg for reasons
      that I am still trying to work out.
      Mark T12757 as fixed
      Reviewers: simonmar, simonpj, austin
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2666
      GHC Trac Issues: #11158
  18. 08 Jun, 2016 1 commit
  19. 24 May, 2016 1 commit
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      Test Plan: ./validate
      Reviewers: goldfire, austin, hvr, bgamari
      Reviewed By: austin, hvr, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2260
  20. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      Test Plan: ./validate
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      Subscribers: goldfire, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D1784
  21. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      (Some of this code is derived from GHCJS.)
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      Reaosns we want this:
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      Things that are not currently implemented for -fexternal-interpreter:
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1562
  22. 21 Aug, 2015 1 commit
    • thomie's avatar
      Refactor: delete most of the module FastTypes · 2f29ebbb
      thomie authored
      This reverses some of the work done in #1405, and goes back to the
      assumption that the bootstrap compiler understands GHC-haskell.
      In particular:
        * use MagicHash instead of _ILIT and _CLIT
        * pattern matching on I# if possible, instead of using iUnbox
        * use Int#/Char#/Addr# instead of the following type synonyms:
          - type FastInt   = Int#
          - type FastChar  = Char#
          - type FastPtr a = Addr#
        * inline the following functions:
          - iBox           = I#
          - cBox           = C#
          - fastChr        = chr#
          - fastOrd        = ord#
          - eqFastChar     = eqChar#
          - shiftLFastInt  = uncheckedIShiftL#
          - shiftR_FastInt = uncheckedIShiftRL#
          - shiftRLFastInt = uncheckedIShiftRL#
        * delete the following unused functions:
          - minFastInt
          - maxFastInt
          - uncheckedIShiftRA#
          - castFastPtr
          - panicDocFastInt and pprPanicFastInt
        * rename panicFastInt back to panic#
      These functions remain, since they actually do something:
        * iUnbox
        * bitAndFastInt
        * bitOrFastInt
      Test Plan: validate
      Reviewers: austin, bgamari
      Subscribers: rwbarton
      Differential Revision: https://phabricator.haskell.org/D1141
      GHC Trac Issues: #1405
  23. 30 Mar, 2015 1 commit
    • Joachim Breitner's avatar
      Refactor the story around switches (#10137) · de1160be
      Joachim Breitner authored
      This re-implements the code generation for case expressions at the Stg →
      Cmm level, both for data type cases as well as for integral literal
      cases. (Cases on float are still treated as before).
      The goal is to allow for fancier strategies in implementing them, for a
      cleaner separation of the strategy from the gritty details of Cmm, and
      to run this later than the Common Block Optimization, allowing for one
      way to attack #10124. The new module CmmSwitch contains a number of
      notes explaining this changes. For example, it creates larger
      consecutive jump tables than the previous code, if possible.
      nofib shows little significant overall improvement of runtime. The
      rather large wobbling comes from changes in the code block order
      (see #8082, not much we can do about it). But the decrease in code size
      alone makes this worthwhile.
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
                  Min          -1.8%      0.0%     -6.1%     -6.1%     -2.9%
                  Max          -0.7%     +0.0%     +5.6%     +5.7%     +7.8%
       Geometric Mean          -1.4%     -0.0%     -0.3%     -0.3%     +0.0%
      Compilation time increases slightly:
              -1 s.d.                -----            -2.0%
              +1 s.d.                -----            +2.5%
              Average                -----            +0.3%
      The test case T783 regresses a lot, but it is the only one exhibiting
      any regression. The cause is the changed order of branches in an
      if-then-else tree, which makes the hoople data flow analysis traverse
      the blocks in a suboptimal order. Reverting that gets rid of this
      regression, but has a consistent, if only very small (+0.2%), negative
      effect on runtime. So I conclude that this test is an extreme outlier
      and no reason to change the code.
      Differential Revision: https://phabricator.haskell.org/D720
  24. 03 Mar, 2015 1 commit
    • thomie's avatar
      Pretty-print # on unboxed literals in core · 89458eba
      thomie authored
      Ticket #10104 dealt with showing the '#'s on types with unboxed fields. This
      commit pretty prints the '#'s on unboxed literals in core output.
      Test Plan: simplCore/should_compile/T8274
      Reviewers: jstolarek, simonpj, austin
      Reviewed By: simonpj, austin
      Subscribers: simonpj, thomie
      Differential Revision: https://phabricator.haskell.org/D678
      GHC Trac Issues: #8274
  25. 02 Mar, 2015 1 commit
  26. 03 Dec, 2014 1 commit
  27. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
  28. 14 Dec, 2012 2 commits
  29. 19 Sep, 2012 1 commit
  30. 17 Sep, 2012 1 commit
  31. 14 Jul, 2012 1 commit
    • Ian Lynagh's avatar
      Implement FastBytes, and use it for MachStr · 7ae1bec5
      Ian Lynagh authored
      This is a first step on the way to refactoring the FastString type.
      FastBytes currently has no unique, mainly because there isn't currently
      a nice way to produce them in Binary.
      Also, we don't currently do the "Dictionary" thing with FastBytes in
      Binary. I'm not sure whether this is important.
      We can change both decisions later, but in the meantime this gets the
      refactoring underway.
  32. 18 Jun, 2012 1 commit
  33. 12 Jun, 2012 1 commit
  34. 06 Jun, 2012 1 commit
  35. 05 Jun, 2012 1 commit
  36. 09 Nov, 2011 2 commits
  37. 04 Nov, 2011 1 commit
  38. 24 Oct, 2011 1 commit