| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19050, we identified several ways in which we could make more illegal
states irrepresentable. This patch introduces a few representation changes
around `Demand` and `Card` with a better and earlier-failing API exported
through pattern synonyms. Specifically,
1. The old enum definition of `Card` led to severely bloated code of operations
on it. I switched to a bit vector representation; much nicer overall IMO.
See Note [Bit vector representation for Card].
Most of the gripes with the old representation were related to where which kind
of `Card` was allowed and the fact that it doesn't make sense for an absent or
bottoming demand to carry a `SubDemand` that describes an evaluation context
that is never realised.
2. So I refactored the `Demand` representation so that it has two new data
constructors for `AbsDmd` and `BotDmd`. The old `(:*)` data constructor
becomes a pattern synonym which expands absent demands as needed, so that
it still forms a complete match and a versatile builder. The new `Demand`
data constructor now carries a `CardNonAbs` and only occurs in a very limited
number of internal call sites.
3. Wherever a full-blown `Card` might end up in a `CardNonAbs` field (like that
of `D` or `Call`), I assert the consistency. When the smart builder of `(:*)`
is called with an absent `Card`, I assert that the `SubDemand` is the same
that we would expand to in the matcher.
4. `Poly` now takes a `CardNonOnce` and encodes the previously noticed invariant
that we never produce `Poly C_11` or `Poly C_01`. I made sure that we never
construct a `Poly` with `C_11` or `C_01`.
Fixes #19050.
We lose a tiny bit of anal perf overall, probably because the new `Demand`
definition can't be unboxed. The biggest loser is WWRec, where allocations go
from 16MB to 26MB in DmdAnal, making up for a total increase of (merely) 1.6%.
It's all within acceptance thresholds.
There are even two ghc/alloc metric decreases. T11545 decreases by *67%*!
Metric Decrease:
T11545
T18304
|
| |
|
|
|
|
|
|
|
|
|
| |
Update submodule libffi-tarballs to upstream commit 4f9e20a.
Remove C compiler flags that suppress warnings in the RTS. Those
warnings have been fixed by libffi upstream.
Fixes #19885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d1f59540e8b7be96b55ab4b286539a70bc75416c.
This commit breaks the build of unordered-containers
```
[3 of 9] Compiling Data.HashMap.Internal.Array ( Data/HashMap/Internal/Array.hs, dist/build/Data/HashMap/Internal/Array.o, dist/build/Data/HashMap/Internal/Array.dyn_o )
*** Parser [Data.HashMap.Internal.Array]:
Parser [Data.HashMap.Internal.Array]: alloc=21043544 time=13.621
*** Renamer/typechecker [Data.HashMap.Internal.Array]:
Renamer/typechecker [Data.HashMap.Internal.Array]: alloc=151218672 time=187.083
*** Desugar [Data.HashMap.Internal.Array]:
ghc: panic! (the 'impossible' happened)
GHC version 9.3.20210625:
expectJust splitFunTy
CallStack (from HasCallStack):
error, called at compiler/GHC/Data/Maybe.hs:68:27 in ghc:GHC.Data.Maybe
expectJust, called at compiler/GHC/Core/Type.hs:1247:14 in ghc:GHC.Core.Type
```
Revert containers submodule update
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a sequel of #19414, I wrote a script that measures min and max allocation
bounds of T12545 based on randomly modifying -dunique-increment. I got a spread
of as much as 4.8%. But instead of widening the acceptance window further (to
5%), I committed the script as part of this commit, so that false positive
increases can easily be diagnosed by comparing min and max bounds to HEAD.
Indeed, for !5814 we have seen T12545 go from -0.3% to 3.3% after a rebase.
I made sure that the min and max bounds actually stayed the same.
In the future, this kind of check can very easily be done in a matter of a
minute. Maybe we should increase the acceptance threshold if we need to check
often (leave a comment on #19414 if you had to check), but I've not been bitten
by it for half a year, which seems OK.
Metric Increase:
T12545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part of fixing #19766 required the emission of `LitRubbish` as absent filler in
places where we used `absentError` before. In WWRec we have the situation that
such bindings occur in the argument to functions. With `LitRubbish` we inlined
those functions, because
1. The absent binding was regarded as ConLike. So I fixed `exprIsHNFLike` to
respond `False` to `LitRubbish`.
2. The other source of inlining was that after inlining such an absent
binding, `LitRubbish` itself was regarded `ValueArg` by `interestingArg`,
leading to more inlining. It now responds `TrivArg` to `LitRubbish`.
Fixes #20035.
There's one slight 1.6% ghc/alloc regression left in T15164 that is due to an
additional specialisation `$s$cget`. I've no idea why that happens; the Core
output before is identical and has the call site that we specialise for.
Metric Decrease:
WWRec
|
|
|
|
| |
The only item left in #17819. Fixes #17819.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5814#note_355144,
Simon noted that `mkWWstr` and `mkWWcpr` could generate fewer let bindings and
be implemented less indirectly by returning the rebuilt expressions directly, e.g. instead of
```
f :: (Int, Int) -> Int
f (x, y) = x+y
==>
f :: (Int, Int) -> Int
f p = case p of (x, y) ->
case x of I# x' ->
case y of I# y' ->
case $wf x' y' of r' ->
let r = I# r' -- immediately returned
in r
f :: Int# -> Int# -> Int#
$wf x' y' = let x = I# x' in -- only used in p
let y = I# y' in -- only used in p
let p = (x, y) in -- only used in the App below
case (\(x,y) -> x+y) p of I# r' ->
r'
```
we know generate
```
f :: (Int, Int) -> Int
f p = case p of (x, y) ->
case x of I# x' ->
case y of I# y' ->
case $wf x' y' of r' ->
I# r' -- 1 fewer let
f :: Int# -> Int# -> Int#
$wf x' y' = case (\(x,y) -> x+y) (I# x, I# y) of I# r' -> -- 3 fewer lets
r'
```
Which is much nicer and makes it easier to comprehend the output of
worker-wrapper pre-Simplification as well as puts less strain on the Simplifier.
I had to drop support for #18983, but we found that it's broken anyway.
Simon is working on a patch that provides a bit more justification.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`mkWWargs`'s job was pushing casts inwards and doing eta expansion to match
the arity with the number of argument demands we w/w for.
Nowadays, we use the Simplifier to eta expand to arity. In fact, in recent years
we have even seen the eta expansion done by w/w as harmful, see Note [Don't eta
expand in w/w]. If a function hasn't enough manifest lambdas, don't w/w it!
What purpose does `mkWWargs` serve in this world? Not a great one, it turns out!
I could remove it by pulling some important bits,
notably Note [Freshen WW arguments] and Note [Join points and beta-redexes].
Result: We reuse the freshened binder names of the wrapper in the
worker where possible (see testuite changes), much nicer!
In order to avoid scoping errors due to lambda-bound unfoldings in worker
arguments, we zap those unfoldings now. In doing so, we fix #19766.
Fixes #19874.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Strong loop-breakers never inline, INLINE pragma or not.
Hence they should be treated as if there was no INLINE pragma on them.
Also not doing Cast W/W for INLINE strong loop-breakers will trip up Strictness
W/W, because it treats them as if there was no INLINE pragma. Subsequently,
that will lead to a panic once Strictness W/W will no longer do eta-expansion,
as we discovered while implementing !5814.
I also renamed to `unfoldingInfo` to `realUnfoldingInfo` and redefined
`unfoldingInfo` to zap the unfolding it returns in case of a strong loop-breaker.
Now the naming and semantics is symmetrical to `idUnfolding`/`realIdUnfolding`.
Now there was no more reason for `hasInlineUnfolding` to operate on `Id`,
because the zapping of strong loop-breaker unfoldings moved from `idUnfolding`
to `unfoldingInfo`, so I refactored it to take `IdInfo` and call it both from
the Simplifier and WorkWrap, making it utterly clear that both checks are
equivalent.
|
|
|
|
|
|
|
|
|
| |
Previously, when using Typeable in a quantified constraint, GHC would
complain that user-specified instances of Typeable aren't allowed. This
was because checking for SigmaCtxt was missing from a check for whether
an instance head is a hand-written binding.
Fixes #20033
|
| |
|
| |
|
|
|
|
|
|
| |
Previously we branched unnecessarily on
IF_NONMOVING_WRITE_BARRIER_ENABLED on every trip through the array
barrier push loop.
|
|
|
|
|
|
|
|
|
| |
Previously the code generator's logic for invoking the nonmoving write
barrier was inconsistent with the write barrier itself. Namely, the code
generator treated the header size argument as being in words whereas the
barrier expected bytes. This was the cause of #19715.
Fixes #19715.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When TemplateHaskellQuotes is enabled, we also generate programs which
mention symbols from the template-haskell module. So that package is
added conditionally if the extension is turned on.
We should really do the same for other wired-in packages:
* base
* ghc-bignum
* ghc-prim
* rts
When we link an executable, we must also link against these
libraries. In accordance with every other package, these dependencies
should be added into the direct dependencies for a module automatically
and end up in the interface file to record the fact the object file was
created by linking against these packages.
Unfortunately it is not so easy to work out when symbols from each of
these libraries ends up in the generated program. You might think that
`base` would always be used but the `ghc-prim` package doesn't depend
on `base`, so you have to be a bit careful and this futher enhancement
is left to a future patch.
|
|
|
|
| |
This fixes an error message regression.
|
| |
|
| |
|
|
|
|
|
|
| |
Fixed in 25977ab542a30df4ae71d9699d015bcdd1ab7cfb
Fixes #17481
|
|
|
|
|
|
| |
This test was fixed by 25977ab542a30df4ae71d9699d015bcdd1ab7cfb
Fixes #18330
|
|
|
|
| |
fixes #17126, updates containers submodule
|
|
|
|
|
| |
config.sub and config.guess aren't used anymore, so they should
be removed from the base.cabal file
|
|
|
|
| |
Thanks to @wz1000 for spotting this oversight.
|
|
|
|
|
|
| |
Often times when attaching a debugger to iserv it's helpful to have
iserv wait a few seconds for the debugger to attach. -wait can be
passed via -opti-wait if needed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Fix linearity error with incomplete MultiWayIf (#20023)
- Fix partial pattern binding error message (#20024)
- Remove obsolete test LinearPolyTest
It tested the special typing rule for ($), which was removed
during the implementation of Quick Look 97cff9190d3.
- Fix ticket numbers in linear/*/all.T, they referred to linear types
issue tracker
|
|
|
|
|
|
|
|
| |
There's no `errorWithCallStack`, only `errorWithStackTrace`, but the latter is
now deprecated, since `error` now defaults to returning a stack strace.
So rather than change this to the intended deprecated function we replace
`errorWithCallStack` with `error` instead.
|
|
|
|
| |
This helps with the import of the results into the performance database.
|
|
|
|
|
|
| |
The "Cabal test" was previously testing the compilation of the very
advanced Setup.hs file. Now we compile the whole library, as the test
intended.
|
|
|
|
|
|
| |
We need to be careful about the sign bit for BR26 relocation
otherwise we end up encoding a large positive number and reading
back a large negative number.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #20029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the intial NCG development, GHC did not have support for
anything below Words. As such the NCG didn't support any of this
either. AArch64-Darwin however needs support for subword, as
arguments in excess of the first eight (8) passed via registers
are passed on the stack, and there in a packed fashion. Thus
ghc learned about subword sizes. This than lead us to gain
subword primops, and these subsequently highlighted deficiencies
in the AArch64 NCG.
This patch rectifies the ones I found through via the test-suite.
I do not claim this to be exhaustive.
Fixes: #19993
Metric Increase:
T10421
T13035
T13719
T14697
T1969
T9203
T9872a
T9872b
T9872c
T9872d
T9961
haddock.Cabal
haddock.base
parsing001
|
| |
|
|
|
|
|
|
|
|
| |
This adds constructors to TcRnMessage to replace use of
TcRnUnknownMessage in Ghc.Tc.Module.
Adds a test case for the UnsafeDueToPlugin warning.
Closes #19926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 58cfcc65 the default for jobs has been "interruptible", this means
that when new commits are pushed to a branch which already has a running
pipeline then the old pipelines for this branch are cancelled.
This includes the master branch, and in particular, new commits merged
to the master branch will cancel the nightly job.
The semantics of pipeline cancelling are actually a bit more complicated
though. The interruptible flag is *per job*, but once a pipeline has run
*any* non-interruptible job, then the whole pipeline is considered
non-interruptible (ref
https://gitlab.com/gitlab-org/gitlab/-/issues/32837). This leads to the
hack in this MR where by default all jobs are `interruptible: True`, but
for pipelines we definitely want to run, there is a dummy job which
happens first, which is `interreuptible: False`. This has the effect of
dirtying the whole pipeline and preventing another push to master from
cancelling it.
For now, this patch solves the immediate problem of making sure nightly
jobs are not cancelled.
In the future, we may want to enable this job also for the master
branch, making that change might mean we need more CI capacity than
currently available.
[skip ci]
Ticket: #19554
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
|
|
|
|
|
|
| |
Cabal explicitly passes options to set the rpath, which we then also try
to set using install_name_tool. Cabal should also pass `-fno-use-rpaths`
to suppress the setting of the rpath from within GHC.
|
| |
|
|
|
|
| |
Fixes #20019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noticed by sgraf, we were still running reqlib tests, even if the
library was not available. The reasons for this were not clear to me as
they would never work and it was causing some issues with empty stderr
files being generated if you used --test-accept.
Now if the required library is not there, the test is just skipped, and
a counter increased to mark the fact.
Perhaps in the future it would be nicer to explicitly record why certain
tests are skipped. Missing libraries causing a skip is a special case
at the moment.
Fixes #20005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exprConApp_maybe
For example:
"\0" is encoded to "C0 80", then the rule would correct use a decoding
function to work out the first character was "C0 80" but then just used
BS.tail so the rest of the string was "80". This resulted in
"\0" being transformed into '\C0\80' : unpackCStringUTF8# "80"
Which is obviously bogus.
I rewrote the function to call utf8UnconsByteString directly and avoid
the roundtrip through Faststring so now the head/tail is computed by the
same call.
Fixes #19976
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `prepare_build_mk` created a build.mk that was overwritten right
after.
This makes the BIGNUM_BACKEND choice take effect, fixing #19953, and
causing the metric increase below in the integer-simple job.
Metric Increase:
space_leak_001
|
| |
|
|
|
|
| |
Just a small typo which propagated through ghc-bignum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove fstName, sndName, fstIdKey, sndIdKey - no longer used,
removed from basicKnownKeyNames
- Remove breakpointId, breakpointCondId, opaqueTyCon, unknownTyCon -
they were used in the old implementation of the GHCi debugger
- Fix typos in comments
- Remove outdated comment in Lint.hs
- Use 'LitRubbish' instead of 'RubbishLit' for consistency
- Remove comment about subkinding - superseded by
Note [Kind Constraint and kind Type]
- Mention ticket ID in a linear types error message
- Fix formatting in using-warnings.rst and linear-types.rst
- Remove comment about 'Any' in Dynamic.hs - Dynamic
now uses Typeable + existential instead of Any
- Remove codeGen/should_compile/T13233.hs
This was added by accident, it is not used and T13233 is already in
should_fail
|
|
|
|
| |
Fixes #19995
|