summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Cleanup some primop constructor nameswip/interal-primop-naming-consistencyJohn Ericson2020-11-273-67/+67
| | | | | | | Harmonize the internal (big sum type) names of the native vs fixed-sized number primops a bit. (Mainly by renaming the former.) No user-facing names are changed.
* Make primop handler indentation more consistentJohn Ericson2020-11-271-49/+49
|
* rts: Allocate MBlocks with MAP_TOP_DOWN on WindowsBen Gamari2020-11-271-1/+4
| | | | | | | As noted in #18991, we would previously allocate heap in low memory. Due to this the linker, which typically *needs* low memory, would end up competing with the heap. In longer builds we end up running out of low memory entirely, leading to linking failures.
* RegAlloc: Add missing raPlatformfield to RegAllocStatsSpillAndreas Klebinger2020-11-262-2/+7
| | | | | | Fixes #18994 Co-Author: Benjamin Maurer <maurer.benjamin@gmail.com>
* Split Up getClosureDataFromHeapRepMatthew Pickering2020-11-261-9/+18
| | | | | | | | | Motivation 1. Don't enforce the repeated decoding of an info table, when the client can cache it (ghc-debug) 2. Allow the constructor information decoding to be overridden, this casues segfaults in ghc-debug
* Remove special case for GHC.ByteCode.InstrMatthew Pickering2020-11-261-3/+1
| | | | | | | | | This was added in https://github.com/nomeata/ghc-heap-view/commit/34935206e51b9c86902481d84d2f368a6fd93423 GHC.ByteCode.Instr.BreakInfo no longer exists so the special case is dead code. Any check like this can be easily dealt with in client code.
* rts: Use RTS_LIKELY in CHECKBen Gamari2020-11-261-2/+2
| | | | | Most compilers probably already infer that `barf` diverges but it nevertheless doesn't hurt to be explicit.
* Set dynamic users-guide TOC spacing (fixes #18554)Tim Barnes2020-11-261-0/+3
|
* Fix toArgRep to support 64-bit reps on all systemsSylvain Henry2020-11-266-65/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | [This is @Ericson2314 writing a commit message for @hsyl20's patch.] (Progress towards #11953, #17377, #17375) `Int64Rep` and `Word64Rep` are currently broken on 64-bit systems. This is because they should use "native arg rep" but instead use "large arg rep" as they do on 32-bit systems, which is either a non-concept or a 128-bit rep depending on one's vantage point. Now, these reps currently aren't used during 64-bit compilation, so the brokenness isn't observed, but I don't think that constitutes reasons not to fix it. Firstly, the linked issues there is a clearly expressed desire to use explicit-bitwidth constructs in more places. Secondly, per [1], there are other bugs that *do* manifest from not threading explicit-bitwidth information all the way through the compilation pipeline. One can therefore view this as one piece of the larger effort to do that, improve ergnomics, and squash remaining bugs. Also, this is needed for !3658. I could just merge this as part of that, but I'm keen on merging fixes "as they are ready" so the fixes that aren't ready are isolated and easier to debug. [1]: https://mail.haskell.org/pipermail/ghc-devs/2020-October/019332.html
* RTS: Fix failed inlining of copy_tag.Andreas Klebinger2020-11-262-8/+18
| | | | | | | | | | | | | | | On windows using gcc-10 gcc failed to inline copy_tag into evacuate. To fix this we now set the always_inline attribute for the various copy* functions in Evac.c. The main motivation here is not the overhead of the function call, but rather that this allows the code to "specialize" for the size of the closure we copy which is often known at compile time. An earlier commit also tried to avoid evacuate_large inlining. But didn't quite succeed. So I also marked evacuate_large as noinline. Fixes #12416
* [Sized Cmm] properly retain sizes.Moritz Angermann2020-11-2671-582/+1067
| | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces all Word<N> = W<N># Word# and Int<N> = I<N># Int# with Word<N> = W<N># Word<N># and Int<N> = I<N># Int<N>#, thus providing us with properly sized primitives in the codegenerator instead of pretending they are all full machine words. This came up when implementing darwinpcs for arm64. The darwinpcs reqires us to pack function argugments in excess of registers on the stack. While most procedure call standards (pcs) assume arguments are just passed in 8 byte slots; and thus the caller does not know the exact signature to make the call, darwinpcs requires us to adhere to the prototype, and thus have the correct sizes. If we specify CInt in the FFI call, it should correspond to the C int, and not just be Word sized, when it's only half the size. This does change the expected output of T16402 but the new result is no less correct as it eliminates the narrowing (instead of the `and` as was previously done). Bumps the array, bytestring, text, and binary submodules. Co-Authored-By: Ben Gamari <ben@well-typed.com> Metric Increase: T13701 T14697
* CmmToLlvm: Declare signature for memcmpwip/angerman/arm64Ben Gamari2020-11-246-8/+47
| | | | | | Otherwise `opt` fails with: error: use of undefined value '@memcmp$def'
* gitlab-ci: Run LLVM builds on Debian 10Ben Gamari2020-11-241-17/+17
| | | | The current Debian 9 image doesn't provide LLVM 7.
* gitlab-ci: Run LLVM job on appropriately-labelled MRsBen Gamari2020-11-241-2/+3
| | | | Namely, those marked with the ~"LLVM backend" label
* rts: Flush eventlog buffers from flushEventLogBen Gamari2020-11-2411-11/+75
| | | | | | | | | | | | As noted in #18043, flushTrace failed flush anything beyond the writer. This means that a significant amount of data sitting in capability-local event buffers may never get flushed, despite the users' pleads for us to flush. Fix this by making flushEventLog flush all of the event buffers before flushing the writer. Fixes #18043.
* hadrian: Drop redundant flavour definitionsBen Gamari2020-11-226-94/+5
| | | | | Drop the profiled, LLVM, and ThreadSanitizer flavour definitions as these can now be realized with flavour transformers.
* hadrian: Add profiled_ghc and no_dynamic_ghc modifiersBen Gamari2020-11-222-0/+27
|
* hadrian: Add a viaLlvmBackend modifierBen Gamari2020-11-223-6/+12
| | | | | Note that this also slightly changes the semantics of these flavours as we only use LLVM for >= stage1 builds.
* hadrian: Introduce notion of flavour transformersBen Gamari2020-11-223-5/+104
| | | | This extends Hadrian's notion of "flavour", as described in #18942.
* hadrian: Dump STG when ticky is enabledBen Gamari2020-11-221-1/+7
| | | | | This changes the "ticky" modifier to enable dumping of final STG as this is generally needed to make sense of the ticky profiles.
* Bump time submodule to 1.11.1Ben Gamari2020-11-229-12/+14
| | | | | | Also bumps directory, Cabal, hpc, time, and unix submodules. Closes #18847.
* Implement -ddump-c-backend argumentBen Gamari2020-11-224-1/+19
| | | | To dump output of the C backend.
* rts: Post ticky entry counts to the eventlogBen Gamari2020-11-2114-7/+204
| | | | | | | | We currently only post the entry counters, not the other global counters as in my experience the former are more useful. We use the heap profiler's census period to decide when to dump. Also spruces up the documentation surrounding ticky-ticky a bit.
* hadrian: Disable stripping when debug information is enabledBen Gamari2020-11-211-3/+5
|
* dwarf: Apply info table offset consistentlyBen Gamari2020-11-211-5/+19
| | | | | | | Previously we failed to apply the info table offset to the aranges and DIEs, meaning that we often failed to unwind in gdb. For some reason this only seemed to manifest in the RTS's Cmm closures. Nevertheless, now we can unwind completely up to `main`
* Add regression test for #10504Ryan Scott2020-11-214-0/+15
| | | | | | | This issue was fixed at some point between GHC 8.0 and 8.2. Let's add a regression test to ensure that it stays fixed. Fixes #10504.
* Don't initialize plugins in the Core2Core pipelineSylvain Henry2020-11-212-9/+11
| | | | | Some plugins can be added via TH (cf addCorePlugin). Initialize them in the driver instead of in the Core2Core pipeline.
* Move Plugins into HscEnv (#17957)Sylvain Henry2020-11-2124-159/+204
| | | | | | | | | | Loaded plugins have nothing to do in DynFlags so this patch moves them into HscEnv (session state). "DynFlags plugins" become "Driver plugins" to still be able to register static plugins. Bump haddock submodule
* Introduce -fprof-callers flagBen Gamari2020-11-2119-4/+758
| | | | | | | | This introducing a new compiler flag to provide a convenient way to introduce profiler cost-centers on all occurrences of the named identifier. Closes #18566.
* testsuite: Refactor CountParserDepsBen Gamari2020-11-212-6/+238
|
* users-guide: A bit of clean-up in profiling flag documentationBen Gamari2020-11-211-43/+31
|
* gitlab-ci: Add VERBOSE environment variableBen Gamari2020-11-201-0/+7
| | | | | And change the make build system's default behavior to V=0, greatly reducing build log sizes.
* gitlab-ci: Add usage message to ci.shBen Gamari2020-11-201-0/+58
|
* rts/linker: Align bssSize to page size when mapping symbol extrasBen Gamari2020-11-201-1/+3
| | | | | | | We place symbol_extras right after bss. We also need to ensure that symbol_extras can be mprotect'd independently from the rest of the image. To ensure this we round up the size of bss to a page boundary, thus ensuring that symbol_extras is also page-aligned.
* Find hadrian location more reliably in cabal-install outputGreg Steuck2020-11-201-1/+1
| | | | Fix #18944
* Update user's guide entry on demand analysis and worker/wrapperSebastian Graf2020-11-204-24/+170
| | | | | | | | | The demand signature notation has been undocumented for a long time. The only source to understand it, apart from reading the `Outputable` instance, has been an outdated wiki page. Since the previous commits have reworked the demand lattice, I took it as an opportunity to also write some documentation about notation.
* Demand: Interleave usage and strictness demands (#18903)Sebastian Graf2020-11-2070-1822/+1812
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As outlined in #18903, interleaving usage and strictness demands not only means a more compact demand representation, but also allows us to express demands that we weren't easily able to express before. Call demands are *relative* in the sense that a call demand `Cn(cd)` on `g` says "`g` is called `n` times. *Whenever `g` is called*, the result is used according to `cd`". Example from #18903: ```hs h :: Int -> Int h m = let g :: Int -> (Int,Int) g 1 = (m, 0) g n = (2 * n, 2 `div` n) {-# NOINLINE g #-} in case m of 1 -> 0 2 -> snd (g m) _ -> uncurry (+) (g m) ``` Without the interleaved representation, we would just get `L` for the strictness demand on `g`. Now we are able to express that whenever `g` is called, its second component is used strictly in denoting `g` by `1C1(P(1P(U),SP(U)))`. This would allow Nested CPR to unbox the division, for example. Fixes #18903. While fixing regressions, I also discovered and fixed #18957. Metric Decrease: T13253-spj
* Fix strictness signatures of `prefetchValue*#` primopsSebastian Graf2020-11-201-8/+4
| | | | | | | | | | | | Their strictness signatures said the primops are strict in their first argument, which is wrong: Handing it a thunk will prefetch the pointer to the thunk, but not evaluate it. Hence not strict. The regression test `T8256` actually tests for laziness in the first argument, so GHC apparently never exploited the strictness signature. See also https://gitlab.haskell.org/ghc/ghc/-/issues/8256#note_310867, where this came up.
* Clarify interruptible FFI wrt masking stateKamil Dworakowski2020-11-201-4/+7
|
* Export indexError from GHC.Ix (#18579)Krzysztof Gogolewski2020-11-201-1/+1
|
* PmCheck: Print types of uncovered patterns (#18932)Sebastian Graf2020-11-1857-120/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to avoid confusion as in #18932, we display the type of the match variables in the non-exhaustiveness warning, e.g. ``` T18932.hs:14:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘g’: Patterns of type ‘T a’, ‘T a’, ‘T a’ not matched: (MkT2 _) (MkT1 _) (MkT1 _) (MkT2 _) (MkT1 _) (MkT2 _) (MkT2 _) (MkT2 _) (MkT1 _) (MkT2 _) (MkT2 _) (MkT2 _) ... | 14 | g (MkT1 x) (MkT1 _) (MkT1 _) = x | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` It also allows us to omit the type signature on wildcard matches which we previously showed in only some situations, particularly `-XEmptyCase`. Fixes #18932.
* Add Addr# atomic primops (#17751)Sylvain Henry2020-11-165-135/+349
| | | | This reuses the codegen used for ByteArray#'s atomic primops.
* ghc-bin: Build with eventlogging by defaultBen Gamari2020-11-151-0/+2
| | | | | | We now have all sorts of great facilities using the eventlog which were previously unavailable without building a custom GHC. Fix this by linking with `-eventlog` by default.
* AArch64/arm64 adjustmentsMoritz Angermann2020-11-1530-400/+470
| | | | | | | | This addes the necessary logic to support aarch64 on elf, as well as aarch64 on mach-o, which Apple calls arm64. We change architecture name to AArch64, which is the official arm naming scheme.
* Use tcSplitForAllInvisTyVars (not tcSplitForAllTyVars) in more placesRyan Scott2020-11-1515-29/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of `tcSplitForAllTyVars` in `tcDataFamInstHeader` was the immediate cause of #18939, and replacing it with a new `tcSplitForAllInvisTyVars` function (which behaves like `tcSplitForAllTyVars` but only splits invisible type variables) fixes the issue. However, this led me to realize that _most_ uses of `tcSplitForAllTyVars` in GHC really ought to be `tcSplitForAllInvisTyVars` instead. While I was in town, I opted to replace most uses of `tcSplitForAllTys` with `tcSplitForAllTysInvis` to reduce the likelihood of such bugs in the future. I say "most uses" above since there is one notable place where we _do_ want to use `tcSplitForAllTyVars`: in `GHC.Tc.Validity.forAllTyErr`, which produces the "`Illegal polymorphic type`" error message if you try to use a higher-rank `forall` without having `RankNTypes` enabled. Here, we really do want to split all `forall`s, not just invisible ones, or we run the risk of giving an inaccurate error message in the newly added `T18939_Fail` test case. I debated at some length whether I wanted to name the new function `tcSplitForAllInvisTyVars` or `tcSplitForAllTyVarsInvisible`, but in the end, I decided that I liked the former better. For consistency's sake, I opted to rename the existing `splitPiTysInvisible` and `splitPiTysInvisibleN` functions to `splitInvisPiTys` and `splitPiTysInvisN`, respectively, so that they use the same naming convention. As a consequence, this ended up requiring a `haddock` submodule bump. Fixes #18939.
* Name (tc)SplitForAll- functions more consistentlyRyan Scott2020-11-1531-140/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a zoo of `splitForAll-` functions in `GHC.Core.Type` (as well as `tcSplitForAll-` functions in `GHC.Tc.Utils.TcType`) that all do very similar things, but vary in the particular form of type variable that they return. To make things worse, the names of these functions are often quite misleading. Some particularly egregious examples: * `splitForAllTys` returns `TyCoVar`s, but `splitSomeForAllTys` returns `VarBndr`s. * `splitSomeForAllTys` returns `VarBndr`s, but `tcSplitSomeForAllTys` returns `TyVar`s. * `splitForAllTys` returns `TyCoVar`s, but `splitForAllTysInvis` returns `InvisTVBinder`s. (This in particular arose in the context of #18939, and this finally motivated me to bite the bullet and improve the status quo vis-à-vis how we name these functions.) In an attempt to bring some sanity to how these functions are named, I have opted to rename most of these functions en masse to use consistent suffixes that describe the particular form of type variable that each function returns. In concrete terms, this amounts to: * Functions that return a `TyVar` now use the suffix `-TyVar`. This caused the following functions to be renamed: * `splitTyVarForAllTys` -> `splitForAllTyVars` * `splitForAllTy_ty_maybe` -> `splitForAllTyVar_maybe` * `tcSplitForAllTys` -> `tcSplitForAllTyVars` * `tcSplitSomeForAllTys` -> `tcSplitSomeForAllTyVars` * Functions that return a `CoVar` now use the suffix `-CoVar`. This caused the following functions to be renamed: * `splitForAllTy_co_maybe` -> `splitForAllCoVar_maybe` * Functions that return a `TyCoVar` now use the suffix `-TyCoVar`. This caused the following functions to be renamed: * `splitForAllTy` -> `splitForAllTyCoVar` * `splitForAllTys` -> `splitForAllTyCoVars` * `splitForAllTys'` -> `splitForAllTyCoVars'` * `splitForAllTy_maybe` -> `splitForAllTyCoVar_maybe` * Functions that return a `VarBndr` now use the suffix corresponding to the most relevant type synonym. This caused the following functions to be renamed: * `splitForAllVarBndrs` -> `splitForAllTyCoVarBinders` * `splitForAllTysInvis` -> `splitForAllInvisTVBinders` * `splitForAllTysReq` -> `splitForAllReqTVBinders` * `splitSomeForAllTys` -> `splitSomeForAllTyCoVarBndrs` * `tcSplitForAllVarBndrs` -> `tcSplitForAllTyVarBinders` * `tcSplitForAllTysInvis` -> `tcSplitForAllInvisTVBinders` * `tcSplitForAllTysReq` -> `tcSplitForAllReqTVBinders` * `tcSplitForAllTy_maybe` -> `tcSplitForAllTyVarBinder_maybe` Note that I left the following functions alone: * Functions that split apart things besides `ForAllTy`s, such as `splitFunTys` or `splitPiTys`. Thankfully, there are far fewer of these functions than there are functions that split apart `ForAllTy`s, so there isn't much of a pressing need to apply the new naming convention elsewhere. * Functions that split apart `ForAllCo`s in `Coercion`s, such as `GHC.Core.Coercion.splitForAllCo_maybe`. We could theoretically apply the new naming convention here, but then we'd have to figure out how to disambiguate `Type`-splitting functions from `Coercion`-splitting functions. Ultimately, the `Coercion`-splitting functions aren't used nearly as much as the `Type`-splitting functions, so I decided to leave the former alone. This is purely refactoring and should cause no change in behavior.
* gitlab-ci: Add DWARF release jobs for Debian 10, Fedora27Ben Gamari2020-11-151-2/+24
|
* nativeGen/dwarf: Use DW_AT_linkage instead of DW_AT_MIPS_linkageBen Gamari2020-11-152-3/+3
|
* nativeGen/dwarf: Only produce DW_AT_source_note DIEs in -g3Ben Gamari2020-11-154-8/+16
| | | | | Standard debugging tools don't know how to understand these so let's not produce them unless asked.
* nativeGen/dwarf: Fix procedure end addressesBen Gamari2020-11-154-15/+30
| | | | | | | | | | | | Previously the `.debug_aranges` and `.debug_info` (DIE) DWARF information would claim that procedures (represented with a `DW_TAG_subprogram` DIE) would only span the range covered by their entry block. This omitted all of the continuation blocks (represented by `DW_TAG_lexical_block` DIEs), confusing `perf`. Fix this by introducing a end-of-procedure label and using this as the `DW_AT_high_pc` of procedure `DW_TAG_subprogram` DIEs Fixes #17605.
View Lorry Controller Status