- Mar 05, 2021
-
-
Part of #17804.
-
- Mar 03, 2021
-
-
Matthew Pickering authored
During testing it was observed that quite a few info tables were not being given locations (due to not being assigned source locations, because they were not enclosed by a source note). We can at least give the module name and type for such closures even if no more accurate source information. Especially for constructors this helps find them in the STG dumps.
-
Matthew Pickering authored
-
Matthew Pickering authored
-
Matthew Pickering authored
-
Matthew Pickering authored
-
Matthew Pickering authored
The `whereFrom` function provides a Haskell interface for using the information created by `-finfo-table-map`. Given a Haskell value, the info table address will be passed to the `lookupIPE` function in order to attempt to find the source location information for that particular closure. At the moment it's not possible to distinguish the absense of the map and a failed lookup.
-
Matthew Pickering authored
The `-fdistinct-constructor-tables` flag will generate a fresh info table for the usage of any data constructor. This is useful for debugging as now by inspecting the info table, you can determine which usage of a constructor caused that allocation rather than the old situation where the info table always mapped to the definition site of the data constructor which is useless. In conjunction with `-hi` and `-finfo-table-map` this gives a more fine grained understanding of where constructor allocations arise from in a program.
-
Matthew Pickering authored
This new flag embeds a lookup table from the address of an info table to information about that info table. The main interface for consulting the map is the `lookupIPE` C function > InfoProvEnt * lookupIPE(StgInfoTable *info) The `InfoProvEnt` has the following structure: > typedef struct InfoProv_{ > char * table_name; > char * closure_desc; > char * ty_desc; > char * label; > char * module; > char * srcloc; > } InfoProv; > > typedef struct InfoProvEnt_ { > StgInfoTable * info; > InfoProv prov; > struct InfoProvEnt_ *link; > } InfoProvEnt; The source positions are approximated in a similar way to the source positions for DWARF debugging information. They are only approximate but in our experience provide a good enough hint about where the problem might be. It is therefore recommended to use this flag in conjunction with `-g<n>` for more accurate locations. The lookup table is also emitted into the eventlog when it is available as it is intended to be used with the `-hi` profiling mode. Using this flag will significantly increase the size of the resulting object file but only by a factor of 2-3x in our experience.
-
Matthew Pickering authored
This profiling mode creates bands by the address of the info table for each closure. This provides a much more fine-grained profiling output than any of the other profiling modes. The `-hi` profiling mode does not require a profiling build.
-
Matthew Pickering authored
This reverts commit 1c7c6f1a.
-
As reported in #19432, the rules governing how `DefaultSignatures` are typechecked became stricter in GHC 9.0 due to simplified subsumption. However, this was far from obvious to me after reading the User's Guide section on `DefaultSignatures`. In this patch, I spruce up the documentation in that section so that it mentions these nuances. Resolves #19432.
-
This applies the fix for #19033 to all the other flavours as well.
-
-
The update of the Outputable instance resulted in a slew of documentation changes within Notes that used the old syntax. The most important doc changes are to `Note [Demand notation]` and the user's guide. Fixes #19016.
-
Previously a255b4e3 failed to update the non-profiling codepath.
-
Previously the profiled flavour transformer failed to add the profiled ways to the library and RTS ways lists, resulting in link failures.
-
Thanks @mpickering for finding them!
-
Avoid returning a lazy panic value when leak indicators are disabled.
-
($) is INLINE so there is no reason ($!) shouldn't.
-
This patch exposes three new functions in `GHC.Profiling` which allow heap profiling to be enabled and disabled dynamically. 1. startHeapProfTimer - Starts heap profiling with the given RTS options 2. stopHeapProfTimer - Stops heap profiling 3. requestHeapCensus - Perform a heap census on the next context switch, regardless of whether the timer is enabled or not.
-
The first change makes the array ones use the proper fixed-size types, which also means that just like before, they can be used without explicit conversions with the boxed sized types. (Before, it was Int# / Word# on both sides, now it is fixed sized on both sides). For the second change, don't use "extend" or "narrow" in some of the user-facing primops names for conversions. - Names like `narrowInt32#` are misleading when `Int` is 32-bits. - Names like `extendInt64#` are flat-out wrong when `Int is 32-bits. - `narrow{Int,Word}<N>#` however map a type to itself, and so don't suffer from this problem. They are left as-is. These changes are batched together because Alex happend to use the array ops. We can only use released versions of Alex at this time, sadly, and I don't want to have to have a release thatwon't work for the final GHC 9.2. So by combining these we get all the changes for Alex done at once. Bump hackage state in a few places, and also make that workflow slightly easier for the future. Bump minimum Alex version Bump Cabal, array, bytestring, containers, text, and binary submodules
-
Add Data.Type.Ord Add and update tests Metric Increase: MultiLayerModules
-
-
- Mar 02, 2021
-
-
Fixes #17895.
-
Fixes #17953
-
-
Previously the eventlog infrastructure had a couple of races that could pop up when using the startEventLog/endEventLog interfaces. In particular, stopping and then later restarting logging could result in data preceding the eventlog header, breaking the integrity of the stream. To fix this we rework the invariants regarding the eventlog and generally tighten up the concurrency control surrounding starting and stopping of logging. We also fix an unrelated bug, wherein log events from disabled capabilities could end up never flushed.
-
-
- Mar 01, 2021
-
-
Consider (`T18610`): ```hs f :: Bool -> Int f x = case (x, x) of (True, True) -> 1 (False, False) -> 2 (True, False) -> 3 -- Warning: Redundant ``` The third clause will be flagged as redundant. Nevertheless, the programmer might intend to keep the clause in order to avoid bitrot. After this patch, the programmer can write ```hs g :: Bool -> Int g x = case (x, x) of (True, True) -> 1 (False, False) -> 2 (True, False) | GHC.Exts.considerAccessible -> 3 -- No warning ``` And won't be bothered any longer. See also `Note [considerAccessible]` and the updated entries in the user's guide. Fixes #18610 and #19228.
-
While fixing #18610, I noticed that ```hs f :: Bool -> Int f x = case (x, x) of (True, True) -> 1 (False, False) -> 2 ``` was *not* detected as exhaustive. I tracked it down to `equateUSDFM`, where upon merging equality classes of `x` and `y`, we failed to atually indirect the *representative* `x'` of the equality class of `x` to the representative `y'` of `y`. The fixed code is much more naturally and would I should have written in the first place. I can confirm that the above example now is detected as exhaustive. The commit that fixes #18610 comes directly after and it has `f` above as a regression test, so I saw no need to open a ticket or commit a separate regression test.
-
If the context is missing it is captured as Nothing, rather than putting a noLoc in the ParsedSource. Updates haddock submodule
-
Ticket #19360 showed up a terrible bug in the occurrence analyser, in a situation like this Rec { f = g ; g = ..f... {-# RULE g .. = ...f... #-} } Then f was postInlineUnconditionally, but not in the RULE (which is simplified first), so we had a RULE mentioning a variable that was not in scope. This led me to review (again) the subtle loop-breaker stuff in the occurrence analyser. The actual changes are few, and are largely simplifications. I did a /lot/ of comment re-organising though. There was an unexpected amount of fallout. * Validation failed when compiling the stage2 compiler with profiling on. That turned to tickle a second latent bug in the same OccAnal code (at least I think it was always there), which led me to simplify still further; see Note [inl_fvs] in GHC.Core.Opt.OccurAnal. * But that in turn let me to some strange behaviour in CSE when ticks are in the picture, which I duly fixed. See Note [Dealing with ticks] in GHC.Core.Opt.CSE. * Then I got an ASSERT failure in CoreToStg, which again seems to be a latent bug. See Note [Ticks in applications] in GHC.CoreToStg * I also made one unforced change: I now simplify the RHS of a RULE in the same way as the RHS of a stable unfolding. This can allow a trivial binding to disappear sooner than otherwise, and I don't think it has any downsides. The change is in GHC.Core.Opt.Simplify.simplRules.
-
This is a first step towards #18738.
-
Ticket #19364 helpfully points out that we do not currently take advantage of pushing the result type of an application into the arguments. This makes error messages notably less good. The fix is rather easy: move the result-type unification step earlier. It's even a bit more efficient; in the the checking case we now do one less zonk. See Note [Unify with expected type before typechecking arguments] in GHC.Tc.Gen.App This change generally improves error messages, but it made one worse: typecheck/should_fail/T16204c. That led me to the realisation that a good error can be replaced by a less-good one, which provoked me to change GHC.Tc.Solver.Interact.inertsCanDischarge. It's explained in the new Note [Combining equalities] One other refactoring: I discovered that KindEqOrigin didn't need a Maybe in its type -- a nice simplification.
-
As #19293 realises, this one keeps on flip flopping by 2.5% depending on how many modules there are within the GHC package. We should revert this once we figured out how to fix what's going on.
-
Ben Gamari authored
Metric Decrease: T10421
-
Ben Gamari authored
Previously flushEventLog failed to flush anything but the global event buffer in the non-threaded RTS. Fixes #19436.
-
Ben Gamari authored
The previous approach performed the flush in yieldCapability. However, as pointed out in #19435, this is wrong as it idle capabilities will not go through this codepath. The fix is simple: undo the optimisation, flushing in `flushEventLog` by calling `flushAllCapsEventsBufs` after acquiring all capabilities. Fixes #19435.
-