| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #19731
-------------------------
Metric Decrease:
T11545
Metric Increase:
T12545
T15304
-------------------------
|
| |
|
|
|
|
|
|
| |
This avoids surprises in the non-threaded runtime with
blocked signals killing the process because they're only
blocked in the main thread and not in the ticker thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
|
|
|
|
| |
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`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since d880d6b2e48268f5ed4d3eb751fe24cc833e9221 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now use DsM as the base monad for writing hie files and properly
initialise it from the TcGblEnv.
Before, we would end up reading the interface file from disk for the
module we were currently compiling. The modules iface then ended up in
the EPS causing all sorts of subtle
carnage, including difference in the generated core and haddock emitting
a lot of warnings. With the fix, the
module in the TcGblEnv is set correctly so the lookups happen in the
local name env rather than thinking the identifier comes from an
external package.
Fixes #19693 and #19334
|
|
|
|
|
|
|
|
|
|
| |
There were two different issues:
1. integralFractionalLit needed to be passed an already negated value. (T19680)
2. negateFractionalLit did not actually negate the argument, only
flipped the negation flag. (T19680A)
Fixes #19680
|
| |
|
|
|
|
| |
Fixes #19683
|
|
|
|
| |
follow-up from !4675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This vastly reduces memory usage when compiling with `--make` mode, from
about 900M when compiling Cabal to about 300M.
As a matter of uniformity, it also ensures that reading from an
interface performs the same as using the in-memory cache. We can also
delete all the horrible knot-tying in updateIdInfos.
Goes some way to fixing #13586
Accept new output of tests fixing some bugs along the way
-------------------------
Metric Decrease:
T12545
-------------------------
|
|
|
|
| |
Bumps the `haddock` submodule.
|
|
|
|
| |
Fixes #19688.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #13873 unexpectedly showed that a SPECIALISE pragma made a
program run (a lot) slower, because less specialisation took place
overall. It turned out that the specialiser was missing opportunities
because of quantified type variables.
It was quite easy to fix. The story is given in
Note [Specialising polymorphic dictionaries]
Two other minor fixes in the specialiser
* There is no benefit in specialising data constructor /wrappers/.
(They can appear overloaded because they are given a dictionary
to store in the constructor.) Small guard in canSpecImport.
* There was a buglet in the UnspecArg case of specHeader, in the
case where there is a dead binder. We need a LitRubbish filler
for the specUnfolding stuff. I expanded
Note [Drop dead args from specialisations] to explain.
There is a 4% increase in compile time for T13056, because we generate
more specialised code. This seems OK.
Metric Increase:
T13056
|
| |
|
|
|
|
|
|
| |
Otherwise, if the marge batch has decreased metrics, they will fail on
master which will result in the pipeline being cut short and the
expected metric values for the other jobs will not be updated.
|
|
|
|
|
| |
This makes it more robust to people running it with `quick` flavour and
so on.
|
|
|
|
| |
Fixes #19615
|
|
|
|
|
|
| |
Otherwise, errors can go missing which arise when running the splices.
Fixes #19470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want an accurate SrcSpan for redundant constraints:
• Redundant constraint: Eq a
• In the type signature for:
f :: forall a. Eq a => a -> ()
|
5 | f :: Eq a => a -> ()
| ^^^^
This patch adds some plumbing to achieve this
* New data type GHC.Tc.Types.Origin.ReportRedundantConstraints (RRC)
* This RRC value is kept inside
- FunSigCtxt
- ExprSigCtxt
* Then, when reporting the error in GHC.Tc.Errors, use this SrcSpan
to control the error message: GHC.Tc.Errors.warnRedundantConstraints
Quite a lot of files are touched in a boring way.
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that ghci inserts some ticks around the crucial bit of
the expression. Just like in some of the other rules we now strip the
ticks so that the rule fires more reliably.
It was possible to defeat magicDict by using -fhpc as well, so not just an
issue in ghci.
Fixes #19667 and related to #19673
|
|
|
|
| |
--ignore-perf-failures
|
|
|
|
|
| |
GITLAB_CI_BRANCH env var
See https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
|
|
|
|
|
|
| |
This allows to start iserv by passing port 0 to startSlave,
which in turns allows to get an available port when no
port is known to be free a priori.
|
| |
|
| |
|
| |
|
|
|
|
| |
It isn't used for anything anymore
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch we switch from reading the globally installed
platformConstants file to reading the DerivedConstants.h header file
that is bundled in the RTS unit. When we build the RTS unit itself, we
get it from its includes directories.
The new parser is more efficient and strict than the Read instance for
PlatformConstants and we get about 2.2MB less allocations in every
cases. However it only really shows in tests that don't allocate much,
hence the following metric decreases.
Metric Decrease:
Naperian
T10421
T10547
T12150
T12234
T12425
T13035
T18304
T18923
T5837
T6048
T18140
|
|
|
|
|
|
| |
deriveConstants utility now generates a Haskell parser for
DerivedConstants.h. It can be used to replace the one used to read
platformConstants file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few refactorings made after looking at Core/STG
* Use Doc instead of SDoc in pprASCII to avoid passing the SDocContext
that is never used.
* Inline every SDoc wrappers in GHC.Utils.Outputable to expose Doc
constructs
* Add text/[] rule for empty strings (i.e., text "")
* Use a single occurrence of pprGNUSectionHeader
* Use bangs on Platform parameters and some others
Metric Decrease:
ManyAlternatives
ManyConstructors
T12707
T13035
T13379
T18698a
T18698b
T1969
T3294
T4801
T5321FD
T783
|