summaryrefslogtreecommitdiff
path: root/compiler/simplCore/FloatOut.hs
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Core operations (#13009)Sylvain Henry2020-03-181-757/+0
|
* Modules: Core (#13009)Sylvain Henry2020-03-161-1/+1
| | | | Update submodule: haddock
* Modules: Core (#13009)Sylvain Henry2020-02-261-5/+5
| | | | Update haddock submodule
* Modules: Driver (#13009)Sylvain Henry2020-02-211-1/+1
| | | | submodule updates: nofib, haddock
* Fix typos, via a Levenshtein-style correctorBrian Wignall2020-01-041-1/+1
|
* Add GHC-API logging hooksSylvain Henry2019-12-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | * Add 'dumpAction' hook to DynFlags. It allows GHC API users to catch dumped intermediate codes and information. The format of the dump (Core, Stg, raw text, etc.) is now reported allowing easier automatic handling. * Add 'traceAction' hook to DynFlags. Some dumps go through the trace mechanism (for instance unfoldings that have been considered for inlining). This is problematic because: 1) dumps aren't written into files even with -ddump-to-file on 2) dumps are written on stdout even with GHC API 3) in this specific case, dumping depends on unsafe globally stored DynFlags which is bad for GHC API users We introduce 'traceAction' hook which allows GHC API to catch those traces and to avoid using globally stored DynFlags. * Avoid dumping empty logs via dumpAction/traceAction (but still write empty files to keep the existing behavior)
* Remove Bag fold specialisations (#16969)Richard Lupton2019-08-191-2/+2
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-1/+1
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* remove optionGabor Greif2018-12-211-1/+0
|
* Stomp a few typos and grammarosGabor Greif2018-12-171-2/+2
| | | | Also use 'id'
* Allow top level ticked string literalsBartosz Nitka2018-03-061-20/+12
| | | | | | | | | | | | | | | | | | | | This reverts f5b275a239d2554c4da0b7621211642bf3b10650 and changes the places that looked for `Lit (MachStr _))` to use `exprIsMbTickedLitString_maybe` to unwrap ticks as necessary. Also updated relevant comments. Test Plan: I added 3 new tests that previously reproduced. GHC HEAD now builds with -g Reviewers: simonpj, simonmar, bgamari, hvr, goldfire Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14779 Differential Revision: https://phabricator.haskell.org/D4470
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | 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
* Remove redundant importSimon Peyton Jones2017-02-201-1/+0
|
* Don't tick top-level string literalsBen Gamari2017-02-011-12/+20
| | | | | | | | | | | | | | | | | | | | | This fixes a regression due to D2605 (see #8472) wherein top-level primitive strings would fail to be noticed by CoreToStg as they were wrapped in a tick. This resulted in a panic in CoreToStg due to inconsistent CAF information (or a Core Lint failure, if enabled). Here we document the invariant that unlifted expressions can only sit at top-level if of the form `Lit (MachStr ...)` with no ticks or other embellishments. Moreover, we fix instance of this in `Simplify.prepareRhs` and `FloatOut.wrapTick` where this invariant was being broken. Test Plan: Validate with `-g`. Run testsuite with `WAY=ghci`. Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, akio, scpmw, thomie Differential Revision: https://phabricator.haskell.org/D3051
* Join pointsLuke Maurer2017-02-011-48/+213
| | | | | | | | | | | | | | | | | | | This major patch implements Join Points, as described in https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have to read that page, and especially the paper it links to, to understand what's going on; but it is very cool. It's Luke Maurer's work, but done in close collaboration with Simon PJ. This Phab is a squash-merge of wip/join-points branch of http://github.com/lukemaurer/ghc. There are many, many interdependent changes. Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie Differential Revision: https://phabricator.haskell.org/D2853
* FloatOut: Allow floating through breakpoint ticksBen Gamari2017-01-311-14/+13
| | | | | | | | | | | | | | | | | | I believe this is actually a completely valid thing to do, despite the arguments put forth in #10052. All that was missing was logic in SetLevels to correctly substitute the cloned binders into the breakpoint's free variable list. This is a prerequisite for enabling StaticPointer support in the interpreter. Test Plan: Validate Reviewers: austin, scpmw Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3049
* Fix deprecation warnings from containersErik de Castro Lopo2017-01-301-2/+2
| | | | | | | | | | | | | | | The functions that were causing warnings were deprecated in containers 0.5 and GHC is already using containers 0.5.9.1. Test Plan: validate Reviewers: rwbarton, bgamari, hsyl20, austin, dfeuer Reviewed By: dfeuer Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3036
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-7/+6
| | | | | | | | | | | | | | | | | | | | Summary: 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
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-06-021-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Revert "compiler: make sure we reject -O + HscInterpreted" (again)Austin Seipp2015-05-191-27/+0
| | | | | | Apparently my machine likes this commit, but Harbormaster does not? This reverts commit b199536be25ea046079587933cc73d0a948a0626.
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-05-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Revert D727Austin Seipp2015-05-121-27/+0
| | | | | | | | This caused print007 to fail, so I guess I botched this more than I thought. This is a combination of reverting: "Fix build breakage from 9736c042", commit f35d621. "compiler: make sure we reject -O + HscInterpreted", commit 9736c04.
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-05-111-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Source notes (Core support)Peter Wortmann2014-12-161-6/+8
| | | | | | | | | | | | | | | | | | | | | | This patch introduces "SourceNote" tickishs that link Core to the source code that generated it. The idea is to retain these source code links throughout code transformations so we can eventually relate object code all the way back to the original source (which we can, say, encode as DWARF information to allow debugging). We generate these SourceNotes like other tickshs in the desugaring phase. The activating command line flag is "-g", consistent with the flag other compilers use to decide DWARF generation. Keeping ticks from getting into the way of Core transformations is tricky, but doable. The changes in this patch produce identical Core in all cases I tested -- which at this point is GHC, all libraries and nofib. Also note that this pass creates *lots* of tick nodes, which we reduce somewhat by removing duplicated and overlapping source ticks. This will still cause significant Tick "clumps" - a possible future optimization could be to make Tick carry a list of Tickishs instead of one at a time. (From Phabricator D169)
* compiler: de-lhs simplCore/Austin Seipp2014-12-031-0/+563
Signed-off-by: Austin Seipp <austin@well-typed.com>
View Lorry Controller Status