summaryrefslogtreecommitdiff
path: root/compiler/cmm/CmmProcPoint.hs
Commit message (Collapse)AuthorAgeFilesLines
* Module hierarchy: Cmm (cf #13009)Sylvain Henry2020-01-251-496/+0
|
* Remove unused imports of the form 'import foo ()' (Fixes #17065)James Foster2019-08-151-1/+1
| | | | | | | | | | | These kinds of imports are necessary in some cases such as importing instances of typeclasses or intentionally creating dependencies in the build system, but '-Wunused-imports' can't detect when they are no longer needed. This commit removes the unused ones currently in the code base (not including test files or submodules), with the hope that doing so may increase parallelism in the build system by removing unnecessary dependencies.
* Move 'Platform' to ghc-bootJohn Ericson2019-06-191-1/+1
| | | | | | | 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.
* Fix unused-import warningsDavid Eichmann2018-11-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312
* CmmUtils: get rid of insertBlockMichal Terepeta2018-03-191-4/+4
| | | | | | | | | | | | | | | | | | | `Hoopl.Graph` has almost exactly the same function, so let's use that. Also, use `IntMap.alter` to make it more efficient. Also switch `Hoopl` to use strict maps. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: dfeuer, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4493
* Hoopl: improve postorder calculationMichal Terepeta2018-03-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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>` and `postorder_dfs_from <label X>` would actually mean quite different things (and give different results). - 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 <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4464
* cmm/: Avoid using lazy left foldsMichal Terepeta2018-03-061-4/+5
| | | | | | | | | | | | | | | | | | This basically replaces all uses of `foldl` with `foldl'`. I've looked at all the call sites and there doesn't seem to be any reason to prefer the lazy version. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4463
* Hoopl.Collections: change right folds to strict left foldsMichal Terepeta2018-02-021-10/+10
| | | | | | | | | | | | | | | | | | | | | | It seems that most uses of these folds should be strict left folds (I could only find a single place that benefits from a right fold). So this removes the existing `setFold`/`mapFold`/`mapFoldWihKey` replaces them with: - `setFoldl`/`mapFoldl`/`mapFoldlWithKey` (strict left folds) - `setFoldr`/`mapFoldr` (for the less common case where a right fold actually makes sense, e.g., `CmmProcPoint`) Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter, kavon Differential Revision: https://phabricator.haskell.org/D4356
* Fix broken LLVM code genMoritz Angermann2017-09-211-2/+3
| | | | | | | | | | | | | | | In 8b007abbeb30 (nativeGen: Consistently use blockLbl to generate CLabels from BlockIds) all blockLbls were changed. This interfered with the `toInfoLbl` call in CmmProcPoint, and caused the LLVM backend to fall over. Reviewers: bgamari, austin, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4006
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-1/+1
| | | | | | | | | | | | | | | | | | 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
* nativeGen: A few strictness fixesBen Gamari2017-09-141-3/+3
| | | | | | | | | | Test Plan: Validate Reviewers: austin, simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3948
* Hoopl: remove dependency on Hoopl packageMichal Terepeta2017-06-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This copies the subset of Hoopl's functionality needed by GHC to `cmm/Hoopl` and removes the dependency on the Hoopl package. The main motivation for this change is the confusing/noisy interface between GHC and Hoopl: - Hoopl has `Label` which is GHC's `BlockId` but different than GHC's `CLabel` - Hoopl has `Unique` which is different than GHC's `Unique` - Hoopl has `Unique{Map,Set}` which are different than GHC's `Uniq{FM,Set}` - GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is needed just to filter the exposed functions (filter out some of the Hoopl's and add the GHC ones) With this change, we'll be able to simplify this significantly. It'll also be much easier to do invasive changes (Hoopl is a public package on Hackage with users that depend on the current behavior) This should introduce no changes in functionality - it merely copies the relevant code. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: simonpj, kavon, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3616
* procPointAnalysis doesn't need UniqSMMichal Terepeta2016-12-151-32/+26
| | | | | | | | | | | | | | | | | | `procPointAnalysis` doesn't need to run in `UniqSM` (it consists of a single `return` and the call to `analyzeCmm` function which is pure). Making it non-monadic simplifies the code a bit. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2837
* BlockId: remove BlockMap and BlockSet synonymsMichal Terepeta2016-12-081-5/+5
| | | | | | | | | | | | | | | | | | | | This continues removal of `BlockId` module in favor of Hoopl's `Label`. Most of the changes here are mechanical, apart from the orphan `Outputable` instances for `LabelMap` and `LabelSet`. For now I've moved them to `cmm/Hoopl`, since it's already trying to manage all imports from Hoopl (to avoid any collisions). Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2800
* Hoopl/Dataflow: use block-oriented interfaceMichal Terepeta2016-11-291-36/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the new interface for dataflow analysis, where transfer functions operate on a whole basic block. The main changes are: - Hoopl.Dataflow: implement the new interface and remove the old code; expose a utility function to do a strict fold over the nodes of a basic block (for analyses that do want to look at all the nodes) - Refactor all the analyses to use the new interface. One of the nice effects is that we can remove the `analyzeFwdBlocks` hack that ignored the middle nodes (that existed for analyses that didn't need to go over all the nodes). Now this is no longer a special case and fits well with the new interface. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate, earlier version of the patch had assertions comparing the results with the old implementation Reviewers: erikd, austin, simonmar, hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: goldfire, erikd, thomie Differential Revision: https://phabricator.haskell.org/D2754
* Remove most functions from cmm/BlockIdMichal Terepeta2016-11-291-5/+19
| | | | | | | | | | | | | | | | | | | | It seems that `BlockId` module could simply go away in favor of Hoopl's `Label`. This is the first step to do that. In a few places I had to add some type signatures, but most of them seem to help with code readability. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2765
* Hoopl/Dataflow: make the module more self-containedMichal Terepeta2016-11-021-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | This makes the GHC's Dataflow module more self-contained by also forking the `DataflowLattice` (instead of only the analysis algorithm). Effects/benefits: - We no longer need to use the deprecated Hoopl functions (and can remove `-fno-warn-warnings-deprecations` from two modules). - We can remove the unnecessary `Label` parameter of `JoinFun` (already ignored in all our implementations). - We no longer mix Hoopl's `Dataflow` module and GHC's one. - We can replace some calls to lazy folds in Hoopl with the strict ones (see `joinOutFacts` and `mkFactBase`). Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2660
* CmmUtils: remove the last dataflow functionsMichal Terepeta2016-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | This commit: - Moves the remaining few methods concerned with dataflow analysis from `CmmUtils` to `Hoopl.Dataflow`. - Refactors the code to not use `FwdPass` and simply pass `FwdTransfer` and `DataflowLattice` directly. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2634
* Annotate CmmBranch with an optional likely targetSimon Marlow2015-09-231-2/+2
| | | | | | | | | | | | | | | | | Summary: This allows the code generator to give hints to later code generation steps about which branch is most likely to be taken. Right now it is only taken into account in one place: a special case in CmmContFlowOpt that swapped branches over to maximise the chance of fallthrough, which is now disabled when there is a likelihood setting. Test Plan: validate Reviewers: austin, simonpj, bgamari, ezyang, tibbe Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1273
* Refactor the story around switches (#10137)Joachim Breitner2015-03-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tick scopesPeter Wortmann2014-12-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | This patch solves the scoping problem of CmmTick nodes: If we just put CmmTicks into blocks we have no idea what exactly they are meant to cover. Here we introduce tick scopes, which allow us to create sub-scopes and merged scopes easily. Notes: * Given that the code often passes Cmm around "head-less", we have to make sure that its intended scope does not get lost. To keep the amount of passing-around to a minimum we define a CmmAGraphScoped type synonym here that just bundles the scope with a portion of Cmm to be assembled later. * We introduce new scopes at somewhat random places, aligning with getCode calls. This works surprisingly well, but we might have to add new scopes into the mix later on if we find things too be too coarse-grained. (From Phabricator D169)
* Drop proc-points that don't exist in the graph (#8205)Jan Stolarek2013-09-111-17/+47
| | | | | | | | On some architectures it might happen that stack layout pass will invalidate the list of calculated procpoints by dropping some of them. We fix this by checking whether a proc-point is in a graph at the beginning of proc-point analysis. This is a speculative fix for #8205.
* Remove unnecessary warnings suppressions, fixes ticket #7756; thanks ↵Edward Z. Yang2013-03-091-1/+0
| | | | | | monoidal for submitting. Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
* Rename all of the 'cmmz' flags and make them more consistent.Austin Seipp2012-12-191-1/+1
| | | | | | | | | | | | | | | | There's only a single compiler backend now, so the 'z' suffix means nothing. Also, the flags were confusingly named ('cmm-foo' vs 'foo-cmm',) and counter-intuitively, '-ddump-cmm' did not do at all what you expected since the new backend went live. Basically, all of the -ddump-cmmz-* flags are now -ddump-cmm-*. Some were renamed to be more consistent. This doesn't update the manual; it already mentions '-ddump-cmm' and that flag implies all the others anyway, which is probably what you want. Signed-off-by: Austin Seipp <mad.one@gmail.com>
* replaceLabels: null out the cml_cont field of CmmCallSimon Marlow2012-11-121-1/+4
| | | | This fixes a CmmLint complaint when doing proc-point splitting.
* Attach global register liveness info to Cmm procedures.Geoffrey Mainland2012-10-301-9/+16
| | | | | | | All Cmm procedures now include the set of global registers that are live on procedure entry, i.e., the global registers used to pass arguments to the procedure. Only global registers that are use to pass arguments are included in this list.
* Avoid calling toInfoLbl on the entry label (#7313)Simon Marlow2012-10-231-20/+23
|
* Produce new-style Cmm from the Cmm parserSimon Marlow2012-10-081-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main change here is that the Cmm parser now allows high-level cmm code with argument-passing and function calls. For example: foo ( gcptr a, bits32 b ) { if (b > 0) { // we can make tail calls passing arguments: jump stg_ap_0_fast(a); } return (x,y); } More details on the new cmm syntax are in Note [Syntax of .cmm files] in CmmParse.y. The old syntax is still more-or-less supported for those occasional code fragments that really need to explicitly manipulate the stack. However there are a couple of differences: it is now obligatory to give a list of live GlobalRegs on every jump, e.g. jump %ENTRY_CODE(Sp(0)) [R1]; Again, more details in Note [Syntax of .cmm files]. I have rewritten most of the .cmm files in the RTS into the new syntax, except for AutoApply.cmm which is generated by the genapply program: this file could be generated in the new syntax instead and would probably be better off for it, but I ran out of enthusiasm. Some other changes in this batch: - The PrimOp calling convention is gone, primops now use the ordinary NativeNodeCall convention. This means that primops and "foreign import prim" code must be written in high-level cmm, but they can now take more than 10 arguments. - CmmSink now does constant-folding (should fix #7219) - .cmm files now go through the cmmPipeline, and as a result we generate better code in many cases. All the object files generated for the RTS .cmm files are now smaller. Performance should be better too, but I haven't measured it yet. - RET_DYN frames are removed from the RTS, lots of code goes away - we now have some more canned GC points to cover unboxed-tuples with 2-4 pointers, which will reduce code size a little.
* splitAtProcPoints: jump to the right place when tablesNextToCode == FalseSimon Marlow2012-09-201-11/+24
|
* New codegen: do not split proc-points when using the NCGSimon Marlow2012-07-301-6/+20
| | | | | | | | | Proc-point splitting is only required by backends that do not support having proc-points within a code block (that is, everything except the native backend, i.e. LLVM and C). Not doing proc-point splitting saves some compilation time, and might produce slightly better code in some cases.
* GHC 7.4 is now required for building HEADIan Lynagh2012-07-201-3/+0
|
* Fix build with GHC 7.0Ian Lynagh2012-07-131-0/+3
|
* Track liveness of GlobalRegs in the new code generatorSimon Marlow2012-07-091-2/+4
| | | | | | This gives the register allocator access to R1.., F1.., D1.. etc. for the new code generator, and is a cheap way to eliminate all the extra "x = R1" assignments that we get from copyIn.
* Remove "fuel", adapt to Hoopl changes, fix warningsSimon Marlow2012-07-051-12/+6
|
* Merge remote-tracking branch 'origin/master' into newcgSimon Marlow2012-07-041-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * origin/master: (756 commits) don't crash if argv[0] == NULL (#7037) -package P was loading all versions of P in GHCi (#7030) Add a Note, copying text from #2437 improve the --help docs a bit (#7008) Copy Data.HashTable's hashString into our Util module Build fix Build fixes Parse error: suggest brackets and indentation. Don't build the ghc DLL on Windows; works around trac #5987 On Windows, detect if DLLs have too many symbols; trac #5987 Add some more Integer rules; fixes #6111 Fix PA dfun construction with silent superclass args Add silent superclass parameters to the vectoriser Add silent superclass parameters (again) Mention Generic1 in the user's guide Make the GHC API a little more powerful. tweak llvm version warning message New version of the patch for #5461. Fix Word64ToInteger conversion rule. Implemented feature request on reconfigurable pretty-printing in GHCi (#5461) ... Conflicts: compiler/basicTypes/UniqSupply.lhs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmStackLayout.hs compiler/cmm/MkGraph.hs compiler/cmm/OldPprCmm.hs compiler/codeGen/CodeGen.lhs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmUtils.hs compiler/main/CodeOutput.lhs compiler/main/HscMain.hs compiler/nativeGen/AsmCodeGen.lhs compiler/simplStg/SimplStg.lhs
| * Remove PlatformOutputableIan Lynagh2012-06-131-1/+1
| | | | | | | | | | We can now get the Platform from the DynFlags inside an SDoc, so we no longer need to pass the Platform in.
* | Remove dead code and optimise a bitSimon Marlow2012-03-151-205/+25
| |
* | Remove the old stack layout algorithmsSimon Marlow2012-03-151-1/+2
| | | | | | | | | | | | | | | | Also, do removeDeadAssignments instead of cmmLiveness before stack allocation, because the former also does liveness analysis, and we can do just one liveness analysis instead of two. The stack layout algorithm doesn't introduce any dead assignments, so this doesn't affect the generated code.
* | New stack layout algorithmSimon Marlow2012-02-081-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Also: - improvements to code generation: push slow-call continuations on the stack instead of generating explicit continuations - remove unused CmmInfo wrapper type (replace with CmmInfoTable) - squash Area and AreaId together, remove now-unused RegSlot - comment out old unused stack-allocation code that no longer compiles after removal of RegSlot
* | snapshot of latest improvementsSimon Marlow2012-01-231-1/+1
| |
* | implement RegSet by Set, not UniqSetSimon Marlow2012-01-201-1/+1
| |
* | SnapshotSimon Marlow2012-01-171-14/+16
| |
* | More codegen refactoring with simonpjSimon Marlow2011-12-191-36/+66
|/
* Remove some legacy codeIan Lynagh2011-10-201-11/+0
| | | | __GLASGOW_HASKELL__ >= 612 is now always true
* Renaming onlySimon Peyton Jones2011-08-251-1/+1
| | | | | CmmTop -> CmmDecl CmmPgm -> CmmGroup
* More refactoring (CgRep)Simon Peyton Jones2011-08-251-1/+0
| | | | | | * Move CgRep (private to old codgen) from SMRep to ClosureInfo * Avoid using CgRep in new codegen * Move SMRep and Bitmap from codeGen/ to cmm/
* Snapshot of codegen refactoring to share with simonpjSimon Marlow2011-08-251-5/+4
|
* Remove last use of entryLblToInfoLblMax Bolingbroke2011-07-291-6/+10
|
* Common up uses of entryLblToInfoLbl in CmmProcPointMax Bolingbroke2011-07-291-20/+21
|
* Put the info CLabel in CmmInfoTable rather than a localness flag, tidy up ↵Max Bolingbroke2011-07-281-1/+1
| | | | some info<->entry conversions
View Lorry Controller Status