summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | rts: Give stack flags proper macrosBen Gamari2019-10-186-10/+18
| | | | | | | | | | | | | | | This were previously quite unclear and will change a bit under the non-moving collector so let's clear this up now.
| * | rts/Capability: A few documentation commentsBen Gamari2019-10-181-0/+5
| | |
| * | rts: Add Note explaining applicability of selector optimisation depth limitBen Gamari2019-10-181-1/+14
| | | | | | | | | | | | This was slightly non-obvious so a note seems deserved.
| * | rts/GC: Add an obvious assertion during block initializationÖmer Sinan Ağacan2019-10-183-5/+18
| |/ | | | | | | | | | | | | Namely ensure that block descriptors are initialized with valid generation numbers. Co-Authored-By: Ben Gamari <ben@well-typed.com>
* | base: Add @since on GHC.IO.Handle.Lock.hUnlockBen Gamari2019-10-231-0/+2
| | | | | | | | | | | | Unfortunately this was introduced in base-4.11.0 (GHC 8.4.1) whereas the other locking primitives were added in base-4.10.0 (GHC 8.2.1).
* | Add new flag for unarised STG dumpsÖmer Sinan Ağacan2019-10-235-45/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously -ddump-stg would dump pre and post-unarise STGs. Now we have a new flag for post-unarise STG and -ddump-stg only dumps coreToStg output. STG dump flags after this commit: - -ddump-stg: Dumps CoreToStg output - -ddump-stg-unarised: Unarise output - -ddump-stg-final: STG right before code gen (includes CSE and lambda lifting)
* | Hadrian: Invoke ghc0 via bash when running tests to fix #17362.Andreas Klebinger2019-10-231-1/+3
| | | | | | | | | | | | | | | | cmd uses RawCommand which uses Windows semantics to find the executable which sometimes seems to fail for unclear reasons. If we invoke ghc via bash then bash will find the ghc executable and the issue goes away.
* | Drop duplicate -optl's from GHC invocationsBen Gamari2019-10-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously the make build system would pass things like `-optl-optl-Wl,-x -optl-optl-Wl,noexecstack` to GHC. This would naturally result in mass confusion as GHC would pass `-optl-Wl,-x` to GCC. GCC would in turn interpret this as `-o ptl-Wl,-x`, setting the output pass of the invocation. The problem that `-optl` was added to the command-line in two places in the build system. Fix this. Fixes #17385.
* | users-guide: Fix :since: for -Wunused-packagesBen Gamari2019-10-231-1/+1
| | | | | | | | Fixes #17382.
* | Performance tests: Reduce acceptance threshold for bytes allocated testsMatthew Pickering2019-10-231-41/+41
| | | | | | | | | | | | | | The "new" performance testing infrastructure resets the baseline after every test so it's easy to miss gradual performance regressions over time. We should at least make these numbers smaller to catch patches which affect performance earlier.
* | Make dynflag argument for withTiming pure.Andreas Klebinger2019-10-2322-71/+93
| | | | | | | | | | | | | | | | | | | | | | | | 19 times out of 20 we already have dynflags in scope. We could just always use `return dflags`. But this is in fact not free. When looking at some STG code I noticed that we always allocate a closure for this expression in the heap. Clearly a waste in these cases. For the other cases we can either just modify the callsite to get dynflags or use the _D variants of withTiming I added which will use getDynFlags under the hood.
* | Bump stm submoduleBen Gamari2019-10-231-0/+0
| |
* | Full abort on validate failure merging `orElse`.Ryan Yates2019-10-233-20/+103
| | | | | | | | | | | | | | | | Previously partial roll back of a branch of an `orElse` was attempted if validation failure was observed. Validation here, however, does not account for what part of the transaction observed inconsistent state. This commit fixes this by fully aborting and restarting the transaction.
* | Fix bug in the x86 backend involving the CFG.Andreas Klebinger2019-10-238-214/+544
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is part two of fixing #17334. There are two parts to this commit: - A bugfix for computing loop levels - A bugfix of basic block invariants in the NCG. ----------------------------------------------------------- In the first bug we ended up with a CFG of the sort: [A -> B -> C] This was represented via maps as fromList [(A,B),(B,C)] and later transformed into a adjacency array. However the transformation did not include block C in the array (since we only looked at the keys of the map). This was still fine until we tried to look up successors for C and tried to read outside of the array bounds when accessing C. In order to prevent this in the future I refactored to code to include all nodes as keys in the map representation. And make this a invariant which is checked in a few places. Overall I expect this to make the code more robust as now any failed lookup will represent an error, versus failed lookups sometimes being expected and sometimes not. In terms of performance this makes some things cheaper (getting a list of all nodes) and others more expensive (adding a new edge). Overall this adds up to no noteable performance difference. ----------------------------------------------------------- Part 2: When the NCG generated a new basic block, it did not always insert a NEWBLOCK meta instruction in the stream which caused a quite subtle bug. During instruction selection a statement `s` in a block B with control of the sort: B -> C will sometimes result in control flow of the sort: ┌ < ┐ v ^ B -> B1 ┴ -> C as is the case for some atomic operations. Now to keep the CFG in sync when introducing B1 we clearly want to insert it between B and C. However there is a catch when we have to deal with self loops. We might start with code and a CFG of these forms: loop: stmt1 ┌ < ┐ .... v ^ stmtX loop ┘ stmtY .... goto loop: Now we introduce B1: ┌ ─ ─ ─ ─ ─┐ loop: │ ┌ < ┐ │ instrs v │ │ ^ .... loop ┴ B1 ┴ ┘ instrsFromX stmtY goto loop: This is simple, all outgoing edges from loop now simply start from B1 instead and the code generator knows which new edges it introduced for the self loop of B1. Disaster strikes if the statement Y follows the same pattern. If we apply the same rule that all outgoing edges change then we end up with: loop ─> B1 ─> B2 ┬─┐ │ │ └─<┤ │ │ └───<───┘ │ └───────<────────┘ This is problematic. The edge B1->B1 is modified as expected. However the modification is wrong! The assembly in this case looked like this: _loop: <instrs> _B1: ... cmpxchgq ... jne _B1 <instrs> <end _B1> _B2: ... cmpxchgq ... jne _B2 <instrs> jmp loop There is no edge _B2 -> _B1 here. It's still a self loop onto _B1. The problem here is that really B1 should be two basic blocks. Otherwise we have control flow in the *middle* of a basic block. A contradiction! So to account for this we add yet another basic block marker: _B: <instrs> _B1: ... cmpxchgq ... jne _B1 jmp _B1' _B1': <instrs> <end _B1> _B2: ... Now when inserting B2 we will only look at the outgoing edges of B1' and everything will work out nicely. You might also wonder why we don't insert jumps at the end of _B1'. There is no way another block ends up jumping to the labels _B1 or _B2 since they are essentially invisible to other blocks. View them as control flow labels local to the basic block if you'd like. Not doing this ultimately caused (part 2 of) #17334.
* | Allow command name resolution for GHCi commands with option `!` #17345Takenobu Tani2019-10-234-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit allows command name resolution for GHCi commands with option `!` as follows: ghci> :k! Int Int :: * = Int This commit changes implementation as follows: Before: * Prefix match with full string including the option `!` (e.g. `k!`) After (this patch): * Prefix match without option suffix `!` (e.g. `k`) * in addition, suffix match with option `!` See also #8305 and #8113
* | eventlog: Dump cost centre stack on each sampleMatthew Pickering2019-10-2310-14/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change it is possible to reconstruct the timing portion of a `.prof` file after the fact. By logging the stacks at each time point a more precise executation trace of the program can be observed rather than all identical cost centres being identified in the report. There are two new events: 1. `EVENT_PROF_BEGIN` - emitted at the start of profiling to communicate the tick interval 2. `EVENT_PROF_SAMPLE_COST_CENTRE` - emitted on each tick to communicate the current call stack. Fixes #17322
* | Refactor Compact.c:Ömer Sinan Ağacan2019-10-231-227/+127
| | | | | | | | | | | | | | | | | | - Remove forward declarations - Introduce UNTAG_PTR and GET_PTR_TAG for dealing with pointer tags without having to cast arguments to StgClosure* - Remove dead code - Use W_ instead of StgWord - Use P_ instead of StgPtr
* | testsuite: Don't run T7653 in ghci and profiled waysBen Gamari2019-10-231-2/+2
| | | | | | | | | | Currently this routinely fails in the i386 job. See #7653.
* | Reify oversaturated data family instances correctly (#17296)Ryan Scott2019-10-235-21/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `TcSplice` was not properly handling oversaturated data family instances, such as the example in #17296, as it dropped arguments due to carelessly zipping data family instance arguments with `tyConTyVars`. For data families, the number of `tyConTyVars` can sometimes be less than the number of arguments it can accept in a data family instance due to the fact that data family instances can be oversaturated. To account for this, `TcSplice.mkIsPolyTvs` has now been renamed to `tyConArgsPolyKinded` and now factors in `tyConResKind` in addition to `tyConTyVars`. I've also added `Note [Reified instances and explicit kind signatures]` which explains the various subtleties in play here. Fixes #17296.
* | compiler: introduce DynFlags pluginsAlp Mestanogullari2019-10-2311-1/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They have type '[CommandLineOpts] -> Maybe (DynFlags -> IO DynFlags)'. All plugins that supply a non-Nothing 'dynflagsPlugin' will see their updates applied to the current DynFlags right after the plugins are loaded. One use case for this is to superseede !1580 for registering hooks from a plugin. Frontend/parser plugins were considered to achieve this but they respectively conflict with how this plugin is going to be used and don't allow overriding/modifying the DynFlags, which is how hooks have to be registered. This commit comes with a test, 'test-hook-plugin', that registers a "fake" meta hook that replaces TH expressions with the 0 integer literal.
* | Implement a coverage checker for injectivityRichard Eisenberg2019-10-2338-259/+646
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes #16512. There are lots of parts of this patch: * The main payload is in FamInst. See Note [Coverage condition for injective type families] there for the overview. But it doesn't fix the bug. * We now bump the reduction depth every time we discharge a CFunEqCan. See Note [Flatten when discharging CFunEqCan] in TcInteract. * Exploration of this revealed a new, easy to maintain invariant for CTyEqCans. See Note [Almost function-free] in TcRnTypes. * We also realized that type inference for injectivity was a bit incomplete. This means we exchanged lookupFlattenTyVar for rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new function is monadic while the previous one was pure, necessitating some faff in TcInteract. Nothing too bad. * zonkCt did not maintain invariants on CTyEqCan. It's not worth the bother doing so, so we just transmute CTyEqCans to CNonCanonicals. * The pure unifier was finding the fixpoint of the returned substitution, even when doing one-way matching (in tcUnifyTysWithTFs). Fixed now. Test cases: typecheck/should_fail/T16512{a,b}
* | Warn about missing profiled libs when using the Interpreter.Andreas Klebinger2019-10-231-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When GHC itself, or it's interpreter is profiled we need to load profiled libraries as well. This requirement is not always obvious, especially when TH implicilty uses the interpreter. When the libs were not found we fall back to assuming the are in a DLL. This is usually not the case so now we warn users when we do so. This makes it more obvious what is happening and gives users a way to fix the issue. This fixes #17121.
* | Use an IORef for QSemNDavid Feuer2019-10-231-39/+51
| | | | | | | | | | | | | | Replace the outer `MVar` in `QSemN` with an `IORef`. This should probably be lighter, and it removes the need for `uninterruptibleMask`. Previously Differential Revision https://phabricator.haskell.org/D4896
* | Documentation for (&&) and (&&) states that they are lazy in their second ↵Tilman Blumhagen2019-10-221-2/+2
| | | | | | | | argument (fixes #17354)
* | Implement s390x LLVM backend.Stefan Schulze Frielinghaus2019-10-2227-12/+315
| | | | | | | | | | | | This patch adds support for the s390x architecture for the LLVM code generator. The patch includes a register mapping of STG registers onto s390x machine registers which enables a registerised build.
* | Replace freebsd-gnueabihf with freebsdMatthew Bauer2019-10-223-8/+4
| | | | | | | | | | | | | | | | | | | | | | FreeBSD does not support GNU libc, so it makes no sense to use this triple. Most likely previous builds were just using the FreeBSD libc instead of gnueabihf. To fix this, we should just use armv6-unknown-freebsd and armv7-unknown-freebsd triples. Note that both of these are actually "soft-float", not "hard-float". FreeBSD has never officially released hard-float arm32: https://wiki.freebsd.org/ARMTier1
* | CI: Always dump performance metrics.David Eichmann2019-10-227-21/+39
| |
* | Windows: Update tarballs to GCC 9.2 and remove MAX_PATH limit.Tamar Christina2019-10-2026-141/+530
|/
* testsuite: Assert that testsuite ways are knownBen Gamari2019-10-172-28/+50
| | | | | This ensures that all testsuite way names given to `omit_ways`, `only_ways`, etc. are known ways.
* Tiny fixes to comments around flattening.Richard Eisenberg2019-10-172-3/+3
|
* testsuite: Ensure that makefile tests get runBen Gamari2019-10-1711-21/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously `makefile_test` and `run_command` tests could easily end up in a situation where they wouldn't be run if the user used the `only_ways` modifier. The reason is to build the set of a ways to run the test in we first start with a candidate set determined by the test type (e.g. `makefile_test`, `compile_run`, etc.) and then filter that set with the constraints given by the test's modifiers. `makefile_test` and `run_command` tests' candidate sets were simply `{normal}`, and consequently most uses of `only_ways` would result in the test being never run. To avoid this we rather use all ways as the candidate sets for these test types. This may result in a few more testcases than we would like (given that some `run_command` tests are insensitive to way) but this can be fixed by adding modifiers and we would much rather run too many tests than too few. This fixes #16042 and a number of other tests afflicted by the same issue. However, there were a few cases that required special attention: * `T14028` is currently failing and is therefore marked as broken due to #17300 * `T-signals-child` is fragile in the `threaded1` and `threaded2` ways (tracked in #17307)
* Add hyperlinks to PDF/HTML documentation; closes #17342Brian Wignall2019-10-161-1/+1
|
* Make Coverage.TM a newtypeRyan Scott2019-10-161-1/+1
|
* hadrian: Introduce enableDebugInfo flavour transformerBen Gamari2019-10-161-9/+21
| | | | Also refactor things a bit to eliminate repetition.
* Break up TcRnTypes, among other modules.Richard Eisenberg2019-10-1666-2892/+3071
| | | | | | | | | | | | | | | | | | | | | This introduces three new modules: - basicTypes/Predicate.hs describes predicates, moving this logic out of Type. Predicates don't really exist in Core, and so don't belong in Type. - typecheck/TcOrigin.hs describes the origin of constraints and types. It was easy to remove from other modules and can often be imported instead of other, scarier modules. - typecheck/Constraint.hs describes constraints as used in the solver. It is taken from TcRnTypes. No work other than module splitting is in this patch. This is the first step toward homogeneous equality, which will rely more strongly on predicates. And homogeneous equality is the next step toward a dependently typed core language.
* Delete ghctags cabal fileJohn Ericson2019-10-161-23/+0
| | | | | It came back to life in 381c3ae31b68019177f1cd20cb4da2f9d3b7d6c6 by mistake.
* Infer rho-types instead of sigma-types in guard BindStmts and TransStmtsSebastian Graf2019-10-165-5/+18
| | | | | | | | | | | | | In #17343 we saw that we didn't handle the pattern guard `!_ <- undefined` correctly: The `undefined` was never evaluated. Indeed, elaboration failed to insert the invisible type aruments to `undefined`. So `undefined` was trivially a normal-form and in turn never entered. The problem is that we used to infer a sigma-type for the RHS of the guard, the leading qualifiers of which will never be useful in a pattern match situation. Hence we infer a rho-type now. Fixes #17343.
* testsuite: Add test for #8305Takenobu Tani2019-10-163-0/+45
| | | | | | | | This is a test for the current algorithm of GHCi command name resolution. I add this test in preparation for updating GHCi command name resolution. For the current algorithm, see https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ghci.html#the-ghci-files
* Compiling with -S and -fno-code no longer panics (fixes #17143)adithyaov2019-10-164-0/+10
|
* Add loop level analysis to the NCG backend.klebinger.andreas@gmx.at2019-10-169-374/+1775
| | | | | | | | | | | | | | | | | | | | | | | | | | | For backends maintaining the CFG during codegen we can now find loops and their nesting level. This is based on the Cmm CFG and dominator analysis. As a result we can estimate edge frequencies a lot better for methods, resulting in far better code layout. Speedup on nofib: ~1.5% Increase in compile times: ~1.9% To make this feasible this commit adds: * Dominator analysis based on the Lengauer-Tarjan Algorithm. * An algorithm estimating global edge frequences from branch probabilities - In CFG.hs A few static branch prediction heuristics: * Expect to take the backedge in loops. * Expect to take the branch NOT exiting a loop. * Expect integer vs constant comparisons to be false. We also treat heap/stack checks special for branch prediction to avoid them being treated as loops.
* hadrian: Add support for bindist compressors other than XzBen Gamari2019-10-151-11/+31
| | | | Fixes #17351.
* iface: export a few more functions from BinIfaceAlp Mestanogullari2019-10-151-1/+11
|
* Don't skip validity checks for built-in classes (#17355)Ryan Scott2019-10-154-5/+27
| | | | | | | | | | | | | | | | | | | | Issue #17355 occurred because the control flow for `TcValidity.check_valid_inst_head` was structured in such a way that whenever it checked a special, built-in class (like `Generic` or `HasField`), it would skip the most important check of all: `checkValidTypePats`, which rejects nonsense like this: ```hs instance Generic (forall a. a) ``` This fixes the issue by carving out `checkValidTypePats` from `check_valid_inst_head` so that `checkValidTypePats` is always invoked. `check_valid_inst_head` has also been renamed to `check_special_inst_head` to reflect its new purpose of _only_ checking for instances headed by special classes. Fixes #17355.
* Refactor some cruft in TcDerivInfer.inferConstraintsRyan Scott2019-10-155-254/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The latest installment in my quest to clean up the code in `TcDeriv*`. This time, my sights are set on `TcDerivInfer.inferConstraints`, which infers the context for derived instances. This function is a wee bit awkward at the moment: * It's not terribly obvious from a quick glance, but `inferConstraints` is only ever invoked when using the `stock` or `anyclass` deriving strategies, as the code for inferring the context for `newtype`- or `via`-derived instances is located separately in `mk_coerce_based_eqn`. But there's no good reason for things to be this way, so I moved this code from `mk_coerce_based_eqn` to `inferConstraints` so that everything related to inferring instance contexts is located in one place. * In this process, I discovered that the Haddocks for the auxiliary function `inferConstraintsDataConArgs` are completely wrong. It claims that it handles both `stock` and `newtype` deriving, but this is completely wrong, as discussed above—it only handles `stock`. To rectify this, I renamed this function to `inferConstraintsStock` to reflect its actual purpose and created a new `inferConstraintsCoerceBased` function to specifically handle `newtype` (and `via`) deriving. Doing this revealed some opportunities for further simplification: * Removing the context-inference–related code from `mk_coerce_based_eqn` made me realize that the overall structure of the function is basically identical to `mk_originative_eqn`. In fact, I was easily able to combine the two functions into a single `mk_eqn_from_mechanism` function. As part of this merger, I now invoke `atf_coerce_based_error_checks` from `doDerivInstErrorChecks1`. * I discovered that GHC defined this function: ```hs typeToTypeKind = liftedTypeKind `mkVisFunTy` liftedTypeKind ``` No fewer than four times in different modules. I consolidated all of these definitions in a single location in `TysWiredIn`.
* gitlab-ci: Move hadrian-ghc-in-ghci job firstBen Gamari2019-10-142-9/+12
| | | | | This is a very cheap job and can catch a number of "easy" failure modes (e.g. missing imports in the compiler). Let's run it first.
* Mention changes from #16980, #17213 in 8.10.1 release notesRyan Scott2019-10-141-5/+59
| | | | | | | | The fixes for these issues both have user-facing consequences, so it would be good to mention them in the release notes for GHC 8.10.1. While I'm in town, also mention `UnboxedSums` in the release notes entry related to `-fobject-code`.
* Add docs/users_guide/.log to .gitignoreRyan Scott2019-10-141-1/+2
| | | | | | | | | | | | | | | | | | | When the users guide fails to build (as in #17346), a `docs/users_guide/.log` file will be generated with contents that look something like this: ``` WARNING: unknown config value 'latex_paper_size' in override, ignoring /home/rgscott/Software/ghc5/docs/users_guide/ghci.rst:3410: WARNING: u'ghc-flag' reference target not found: -pgmo ?option? /home/rgscott/Software/ghc5/docs/users_guide/ghci.rst:3410: WARNING: u'ghc-flag' reference target not found: -pgmo ?port? Encoding error: 'ascii' codec can't encode character u'\u27e8' in position 132: ordinal not in range(128) The full traceback has been saved in /tmp/sphinx-err-rDF2LX.log, if you want to report the issue to the developers. ``` This definitely should not be checked in to version control, so let's add this to `.gitignore`.
* Add GHCi help message for :def! and :: commandsTakenobu Tani2019-10-131-1/+3
|
* users-guide: Add GHCi's ::<builtin-command> formTakenobu Tani2019-10-131-0/+9
| | | | | | | This commit explicitly adds description about double colon command of GHCi. [skip ci]
* Fix #17334 where NCG did not properly update the CFG.wip/andreask/17334Andreas Klebinger2019-10-137-242/+503
| | | | | | | | | | | | | Statements can change the basic block in which instructions are placed during instruction selection. We have to keep track of this switch of the current basic block as we need this information in order to properly update the CFG. This commit implements this change and fixes #17334. We do so by having stmtToInstr return the new block id if a statement changed the basic block.