1. 25 Feb, 2020 1 commit
  2. 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.
      bff2f24b
  3. 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
      13bb4bf4
  4. 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
      modules.
      
      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
      f63bc730
  5. 11 Jul, 2017 1 commit
    • Ben Gamari's avatar
      Use correct section types syntax for architecture · 9b9f978f
      Ben Gamari authored
      Previously GHC would always assume that section types began with `@` while
      producing assembly, which is not true. For instance, in ARM assembly syntax
      section types begin with `%`. This abstracts out section type pretty-printing
      and adjusts it to correctly account for the target architectures assembly
      flavor.
      
      Reviewers: austin, hvr, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: Phyx, rwbarton, thomie, erikd
      
      GHC Trac Issues: #13937
      
      Differential Revision: https://phabricator.haskell.org/D3712
      9b9f978f
  6. 20 Mar, 2016 1 commit
  7. 04 Feb, 2016 1 commit
    • Georgios Karachalias's avatar
      Overhaul the Overhauled Pattern Match Checker · 28f951ed
      Georgios Karachalias authored
      Overhaul the Overhauled Pattern Match Checker
      
      * Changed the representation of Value Set Abstractions. Instead of
      using a prefix tree, we now use a list of Value Vector Abstractions.
      The set of constraints Delta for every Value Vector Abstraction is the
      oracle state so that we solve everything only once.
      
      * Instead of doing everything lazily, we prune at once (and in general
      everything is much stricter). Hence, an example written with pattern
      guards is checked in almost the same time as the equivalent with
      pattern matching.
      
      * Do not store the covered and the divergent sets at all. Since what we
      only need is a yes/no (does this clause cover anything? Does it force
      any thunk?) We just keep a boolean for each.
      
      * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`.
      Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should
      the default `n` be.
      
      * When a guard is for sure not going to contribute anything, we treat
      it as such: The oracle is not called and cases `CGuard`, `UGuard` and
      `DGuard` from the paper are not happening at all (the generation of a
      fresh variable, the unfolding of the pattern list etc.). his combined
      with the above seems to be enough to drop the memory increase for test
      T783 down to 18.7%.
      
      * Do not export function `dsPmWarn` (it is now called directly from
      within `checkSingle` and `checkMatches`).
      
      * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle
      does not handle type information so using `Id` was a waste of
      time/space.
      
      * Added testcases T11195, T11303b (data families) and T11374
      
      The patch addresses at least the following:
      Trac #11195, #11276, #11303, #11374, #11162
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, hvr, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1795
      28f951ed
  8. 27 Dec, 2015 1 commit
    • Georgios Karachalias's avatar
      Adding flags: -ffull-guard-reasoning and too-many-guards · bec5350d
      Georgios Karachalias authored
      Introduction of two new flags, for more precise control over the new
      pattern match checker's behaviour when reasoning about guards. This is
      supposed to address #11195 (and maybe more performance bugs related to
      the NP-Hardness of coverage checking).
      
      Expected behaviour:
      
        * When `-ffull-guard-reasoning` is on, run the new pattern match
          checker in its full power
      
        * When `-ffull-guard-reasoning` is off (the default), for every
          match, check a metric to see whether pattern match checking for it
          has high probability of being non performant (at the the moment we
          check whether the number of guards is over 20 but I would like to
          use a more precise measure in the future). If the probability is
          high:
      
          - Oversimplify the guards (less expressive but more performant)
            and run the checker, and
      
          - Issue a warning about the simplification that happened.
      
      A new flag `-Wtoo-many-guards/-Wno-too-many-guards` suppresses the
      warning about the simplification (useful when combined with -Werror).
      
      Test Plan: validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1676
      
      GHC Trac Issues: #11195
      bec5350d
  9. 23 Nov, 2015 1 commit
  10. 01 Nov, 2015 1 commit
  11. 29 Aug, 2015 2 commits
  12. 11 Jun, 2015 1 commit
    • Peter Wortmann's avatar
      Fix DWARF generation for MinGW (#10468) · a66ef356
      Peter Wortmann authored
      Fortunately this is relatively straightforward - all we need to do is
      switch to a non-ELF-specific way of specifying object file sections and
      make sure that section-relative addresses work correctly. This is enough
      to make "gdb" work on MinGW builds.
      a66ef356
  13. 13 Jan, 2015 1 commit
    • Peter Wortmann's avatar
      Dwarf generation fixed pt 2 · 36df0988
      Peter Wortmann authored
      - Don't bracket HsTick expression uneccessarily
      - Generate debug information in UTF8
      - Reduce amount of information generated - we do not currently need
        block information, for example.
      
      Special thanks to slyfox for the reports!
      36df0988
  14. 17 Dec, 2014 2 commits
    • Peter Wortmann's avatar
      Generate DWARF unwind information · edd6d676
      Peter Wortmann authored
      This tells debuggers such as GDB how to "unwind" a program state,
      which allows them to walk the stack up.
      
      Notes:
      
      * The code is quite general, perhaps unnecessarily so. Unless we get
        more unwind information, only the first case of pprSetUnwind will
        get used - and pprUnwindExpr and pprUndefUnwind will never be
        called. It just so happens that this is a point where we can get a
        lot of features cheaply, even if we don't use them.
      
      * When determining what location to show for a return address, most
        debuggers check the map for "rip-1", assuming that's where the
        "call" instruction is. For tables-next-to-code, that happens to
        always be the end of an info table. We therefore cheat a bit here by
        shifting .debug_frame information so it covers the end of the info
        table, as well as generating a .loc directive for the info table
        data.
      
        Debuggers will still show the wrong label for the return address,
        though.  Haven't found a way around that one yet.
      
      (From Phabricator D396)
      edd6d676
    • Peter Wortmann's avatar
      Generate DWARF info section · cc481ec8
      Peter Wortmann authored
      This is where we actually make GHC emit DWARF code. The info section
      contains all the general meta information bits as well as an entry for
      every block of native code.
      
      Notes:
      
      * We need quite a few new labels in order to properly address starts
        and ends of blocks.
      
      * Thanks to Nathan Howell for taking the iniative to get our own Haskell
        language ID for DWARF!
      
      (From Phabricator D396)
      cc481ec8