- Apr 28, 2021
-
-
-
-
Previously -ddump-inlinings and -dverbose-core2core used in conjunction would have the side-effect of dumping additional information about all inlinings considered by the simplifier. However, I have sometimes wanted this inlining information without the firehose of information produced by -dverbose-core2core. Introduce a new dump flag for this purpose.
-
- Apr 27, 2021
-
-
Previously, the `Outputable` instance for `HsArg` was being used to pretty-print each `HsArgPar` in a list of `HsArg`s individually, which simply doesn't work. In lieu of the `Outputable` instance, we now use a dedicated `pprHsArgsApp` function to print a list of `HsArg`s as a single unit. I have also added documentation to the `Outputable` instance for `HsArg` to more clearly signpost that it is only suitable for debug pretty-printing. Fixes #19737.
-
-
-
fix #18000
-
Previously we would check only that the *start* of the mapping was in the bottom 32-bits of address space. However, we need the *entire* mapping to be in low memory. Fix this. Noticed by @Phyx.
-
-
The main idea here is to avoid treating * case e of {} * case unsafeEqualityProof of UnsafeRefl co -> blah specially in CoreToStg. Instead, nail them in CorePrep, by converting case e of {} ==> e |> unsafe-co case unsafeEqualityProof of UnsafeRefl cv -> blah ==> blah[unsafe-co/cv] in GHC.Core.Prep. Now expressions that we want to treat as trivial really are trivial. We can get rid of cpExprIsTrivial. And we fix #19700. A downside is that, at least under unsafeEqualityProof, we substitute in types and coercions, which is more work. But a big advantage is that it's all very simple and principled: CorePrep really gets rid of the unsafeCoerce stuff, as it does empty case, runRW#, lazyId etc. I've updated the overview in GHC.Core.Prep, and added Note [Unsafe coercions] in GHC.Core.Prep Note [Implementing unsafeCoerce] in base:Unsafe.Coerce We get 3% fewer bytes allocated when compiling perf/compiler/T5631, which uses a lot of unsafeCoerces. (It's a happy-generated parser.) Metric Decrease: T5631 -
Before we would get the incorrect error message saying that the rexporting package was the same as the defining package. I think this only affects error messages for now. ``` - it is bound as p-0.1.0.0:P2 by a reexport in package p-0.1.0.0 - it is bound as P by a reexport in package p-0.1.0.0 + it is bound as p-0.1.0.0:P2 by a reexport in package q-0.1.0.0 + it is bound as P by a reexport in package r-0.1.0.0 ``` and the output of `-ddump-mod-map` claimed.. ``` Moo moo-0.0.0.1 (hidden package, reexport by moo-0.0.0.1) ```
-
-
See #15304.
-
-
Previously Unarise would happily project lifted and unlifted fields to lifted slots. This broke horribly in #19645, where a ByteArray# was passed in a lifted slot and consequently entered. The simplest way to fix this is what I've done here, distinguishing between lifted and unlifted slots in unarise. However, one can imagine more clever solutions, where we coerce the binder to the correct levity with respect to the sum's tag. I doubt that this would be worth the effort. Fixes #19645.
-
-
Using `UnliftedNewtypes`, unboxed tuples and sums and a few pattern synonyms, we can make `ParseResult` completely allocation-free. Part of #19263.
-
- Apr 23, 2021
-
-
Adam Gundry authored
I tend to find Notes by (case-sensitive) grep, and I spent a surprisingly long time looking for this Note, because it was referenced inconsistently with different cases, and without the module name.
-
- Apr 22, 2021
-
-
-
-
Also some code cleanup, and a fix for an (extant unrelated) missing <pthread_np.h> include that should hopefully resolve a failure in the FreeBSD CI build, since it is best to make sure that this MR actually builds on FreeBSD systems other than mine. Some unexpected metric changes on FreeBSD (perhaps because CI had been failing for a while???): Metric Decrease: T3064 T5321Fun T5642 T9020 T12227 T13253-spj T15164 T18282 WWRec Metric Increase: haddock.compiler -
The FreeBSD C <ctype.h> header supports per-thread locales by exporting a static inline function that references the `_ThreadRuneLocale` thread-local variable. This means that object files that use e.g. isdigit(3) end up with TLSGD(19) relocations, and would not load into ghci or the language server. Here we add support for this type of relocation, for now just on FreeBSD, and only for external references to thread-specifics defined in already loaded dynamic modules (primarily libc.so). This is sufficient to resolve the <ctype.h> issues. Runtime linking of ".o" files which *define* new thread-specific variables would be noticeably more difficult, as this would likely require new rtld APIs.
-
Previously existing in 'DynFlags', 'nextWrapperNum' is a global variable mapping a Module to a number for name generation for FFI calls. This is not the right location for 'nextWrapperNum', as 'DynFlags' should not contain just about any global variable.
-
When -dynamic-too is enabled, there are two result files, .o and .dyn_o, therefore we should check both to decide whether to set SourceModified or not. The whole recompilation logic is very messy, a more thorough refactor would be beneficial in this area but this is the minimal patch to fix this more high priority problem. Fixes #17968 and hopefully #17534
-
- Apr 21, 2021
-
-
In OccurAnal the function occAnalApp was failing to reset occ_encl to OccVanilla. This omission sometimes resulted in over-pessimistic occurrence information. I tripped over this when analysing eta-expansions. Compile times in perf/compiler fell slightly (no increases) PmSeriesG(normal) ghc/alloc 50738104.0 50580440.0 -0.3% PmSeriesS(normal) ghc/alloc 64045284.0 63739384.0 -0.5% PmSeriesT(normal) ghc/alloc 94430324.0 93800688.0 -0.7% PmSeriesV(normal) ghc/alloc 63051056.0 62758240.0 -0.5% T10547(normal) ghc/alloc 29322840.0 29307784.0 -0.1% T10858(normal) ghc/alloc 191988716.0 189801744.0 -1.1% T11195(normal) ghc/alloc 282654016.0 281839440.0 -0.3% T11276(normal) ghc/alloc 142994648.0 142338688.0 -0.5% T11303b(normal) ghc/alloc 46435532.0 46343376.0 -0.2% T11374(normal) ghc/alloc 256866536.0 255653056.0 -0.5% T11822(normal) ghc/alloc 140210356.0 138935296.0 -0.9% T12234(optasm) ghc/alloc 60753880.0 60720648.0 -0.1% T14052(ghci) ghc/alloc 2235105796.0 2230906584.0 -0.2% T17096(normal) ghc/alloc 297725396.0 296237112.0 -0.5% T17836(normal) ghc/alloc 1127785292.0 1125316160.0 -0.2% T17836b(normal) ghc/alloc 54761928.0 54637592.0 -0.2% T17977(normal) ghc/alloc 47529464.0 47397048.0 -0.3% T17977b(normal) ghc/alloc 42906972.0 42809824.0 -0.2% T18478(normal) ghc/alloc 777385708.0 774219280.0 -0.4% T18698a(normal) ghc/alloc 415097664.0 409009120.0 -1.5% GOOD T18698b(normal) ghc/alloc 500082104.0 493124016.0 -1.4% GOOD T18923(normal) ghc/alloc 72252364.0 72216016.0 -0.1% T1969(normal) ghc/alloc 811581860.0 804883136.0 -0.8% T5837(normal) ghc/alloc 37688048.0 37666288.0 -0.1% Nice! Metric Decrease: T18698a T18698b
-
- Apr 20, 2021
-
-
Sebastian Graf authored
In another small step towards bringing a manageable variant of Nested CPR into GHC, this patch refactors worker/wrapper to be able to exploit Nested CPR signatures. See the new Note [Worker/wrapper for CPR]. The nested code path is currently not triggered, though, because all signatures that we annotate are still flat. So purely a refactoring. I am very confident that it works, because I ripped it off !1866 95% unchanged. A few test case outputs changed, but only it's auxiliary names only. I also added test cases for #18109 and #18401. There's a 2.6% metric increase in T13056 after a rebase, caused by an additional Simplifier run. It appears b1d0b9c saw a similar additional iteration. I think it's just a fluke. Metric Increase: T13056
-
Sebastian Graf authored
-
Sebastian Graf authored
I renamed `wantToUnbox` to `wantToUnboxArg` and then introduced `wantToUnboxResult`, which we call in `mkWWcpr_one` now. I also deleted `splitArgType_maybe` (the single call site outside of `wantToUnboxArg` actually cared about the result type of a function, not an argument) and `splitResultType_maybe` (which is entirely superceded by `wantToUnboxResult`.
-
Sebastian Graf authored
Plus a few minor refactorings: * Introduce `normSplitTyConApp_maybe` to Core.Utils * Reduce boolean blindness in the Bool argument to `wantToUnbox` * Let `wantToUnbox` also decide when to drop an argument, cleaning up `mkWWstr_one`
-
- Apr 19, 2021
-
-
Remove EpaAnn type synonym, rename EpaAnn' to EpaAnn. Closes #19705 Updates haddock submodule -- Change data EpaAnchor = AR RealSrcSpan | AD DeltaPos To instead be data EpaAnchor = AnchorReal RealSrcSpan | AnchorDelta DeltaPos Closes #19699 -- Change data DeltaPos = DP { deltaLine :: !Int, deltaColumn :: !Int } To instead be data DeltaPos = SameLine { deltaColumn :: !Int } | DifferentLine { deltaLine :: !Int, startColumn :: !Int } Closes #19698 -- Also some clean-ups of unused parts of check-exact.
-
This requires adding another rewrite to the mangler, to avoid generating PLT entries.
-
Fixes #19719.
-
-
-
Point out that GHC2021 doesn't offer the same degree of stability that Haskell2010 does, as noted by @phadej.
-
-
- Apr 18, 2021
-
-
Since d880d6b2 the parsing of the environment files was moved to `parseDynamicFlags`, under the assumption it was typically only called once. It turns out not to be true in GHCi and this led to continually reparsing the environment file whenever a new option was set, the options were appended to the package state and hence all packages reloaded, as it looked like the options were changed. The simplest fix seems to be a clearer specification: > Package environment files are only loaded in GHCi during initialisation. Fixes #19650
-
- Apr 17, 2021
-
-
Simon Peyton Jones authored
* Allow under-saturated calls to specialise See Note [SpecConstr call patterns] This just allows a bit more specialisation to take place. * Don't discard calls from un-specialised RHSs. This was a plain bug in `specialise`, again leading to loss of specialisation. Refactoring yields an `otherwise` case that is easier to grok. * I refactored CallPat to become a proper data type, not a tuple. All this came up when I was working on eta-reduction. The ticket is #19672. The nofib results are mostly zero, with a couple of big wins: Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- awards +0.2% -0.1% -18.7% -18.8% 0.0% comp_lab_zift +0.2% -0.2% -23.9% -23.9% 0.0% fft2 +0.2% -1.0% -34.9% -36.6% 0.0% hpg +0.2% -0.3% -18.4% -18.4% 0.0% mate +0.2% -15.7% -19.3% -19.3% +11.1% parser +0.2% +0.6% -16.3% -16.3% 0.0% puzzle +0.4% -19.7% -33.7% -34.0% 0.0% rewrite +0.2% -0.5% -20.7% -20.7% 0.0% -------------------------------------------------------------------------------- Min +0.2% -19.7% -48.1% -48.9% 0.0% Max +0.4% +0.6% -1.2% -1.1% +11.1% Geometric Mean +0.2% -0.4% -21.0% -21.1% +0.1% I investigated the 0.6% increase on 'parser'. It comes because SpecConstr has a limit of 3 specialisations. With HEAD, hsDoExpr has 2 specialisations, and then a further several from the specialised bodies, of which 1 is picked. With this patch we get 3 specialisations right off the bat, so we discard all from the recursive calls. Turns out that that's not the best choice, but there is no way to tell that. I'm accepting it. NB: these figures actually come from this patch plus the preceding one for StgCSE, but I think the gains come from SpecConstr. -
Simon Peyton Jones authored
This patch fixes #19717, a long-standing bug in CSE for STG, which led to a stupid loss of CSE in some situations. It's explained in Note [Trivial case scrutinee], which I have substantially extended.
-
- Apr 15, 2021
-
-
As #19668 showed, there was an /asymptotic/ slow-down in zonking in GHC 9.0, exposed in test T9198. The bug was actually present in earlier compilers, but by a fluke didn't actually show up in any of our tests; but adding Quick Look exposed it. The bug was that in zonkTyVarOcc we 1. read the meta-tyvar-env variable 2. looked up the variable in the env 3. found a 'miss' 4. looked in the variable, found `Indirect ty` 5. zonked `ty` 6. update the env *gotten from step 1* to map the variable to its zonked type. The bug is that we thereby threw away all teh work done in step 4. In T9198 that made an enormous, indeed asymptotic difference. The fix is easy: use updTcRef. I commented in `Note [Sharing when zonking to Type]` ------------------------- Metric Decrease: T9198 -------------------------
-
