| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This fixes an assertion failure in the m32 allocator due to the
imprecisely specified preconditions of `m32_allocator_push_filled_list`.
Specifically, the caller must ensure that the page type is set to filled
prior to calling `m32_allocator_push_filled_list`.
While this issue did result in an assertion failure in the debug RTS,
the issue is in fact benign.
|
| |
|
|
| |
This reverts commit e09afbf2a998beea7783e3de5dce5dd3c6ff23db.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Bumps haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As #21343 showed, we need to be super-certain that the "helper
methods" for Enum instances are actually inlined or specialised.
I also tripped over this when I discovered that numericEnumFromTo
and friends had no pragmas at all, so their performance was very
fragile. If they weren't inlined, all bets were off. So I've added
INLINE pragmas for them too.
See new Note [Inline Enum method helpers] in GHC.Enum.
I also expanded Note [Checking for INLINE loop breakers] in
GHC.Core.Lint to explain why an INLINE function might temporarily
be a loop breaker -- this was the initial bug report in #21343.
Strangely we get a 16% runtime allocation decrease in
perf/should_run/T15185, but only on i386. Since it moves in the right
direction I'm disinclined to investigate, so I'll accept it.
Metric Decrease:
T15185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the unification of concrete type variables.
The subtlety was that unifying concrete metavariables is more subtle
than other metavariables, as decomposition is possible. See the Note
[Unifying concrete metavariables], which explains how we unify a
concrete type variable with a type 'ty' by concretising 'ty', using
the function 'GHC.Tc.Utils.Concrete.concretise'.
This can be used to perform an eager syntactic check for concreteness,
allowing us to remove the IsRefl# special predicate. Instead of emitting
two constraints `rr ~# concrete_tv` and `IsRefl# rr concrete_tv`, we
instead concretise 'rr'. If this succeeds we can fill 'concrete_tv',
and otherwise we directly emit an error message to the typechecker
environment instead of deferring. We still need the error message
to be passed on (instead of directly thrown), as we might benefit from
further unification in which case we will need to zonk the stored types.
To achieve this, we change the 'wc_holes' field of 'WantedConstraints'
to 'wc_errors', which stores general delayed errors. For the moement,
a delayed error is either a hole, or a syntactic equality error.
hasFixedRuntimeRep_MustBeRefl is now hasFixedRuntimeRep_syntactic, and
hasFixedRuntimeRep has been refactored to directly return the most
useful coercion for PHASE 2 of FixedRuntimeRep.
This patch also adds a field ir_frr to the InferResult datatype,
holding a value of type Maybe FRROrigin. When this value is not
Nothing, this means that we must fill the ir_ref field with a type
which has a fixed RuntimeRep.
When it comes time to fill such an ExpType, we ensure that the type
has a fixed RuntimeRep by performing a representation-polymorphism
check with the given FRROrigin
This is similar to what we already do to ensure we fill an Infer
ExpType with a type of the correct TcLevel.
This allows us to properly perform representation-polymorphism checks
on 'Infer' 'ExpTypes'.
The fillInferResult function had to be moved to GHC.Tc.Utils.Unify
to avoid a cyclic import now that it calls hasFixedRuntimeRep.
This patch also changes the code in matchExpectedFunTys to make use
of the coercions, which is now possible thanks to the previous change.
This implements PHASE 2 of FixedRuntimeRep in some situations.
For example, the test cases T13105 and T17536b are now both accepted.
Fixes #21239 and #21325
-------------------------
Metric Decrease:
T18223
T5631
-------------------------
|
| | |
|
| |
|
|
|
| |
Previously the `ipe` and `omit_pragmas` transformers were hackily
defined using the textual key-value syntax. Fix this.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This distills the essence of the Sigs.hs program found in the ticket.
|
| |
|
|
|
|
|
| |
This module exports unsafe pointer equality operations,
so we accordingly mark it as Unsafe.
Fixes #21433
|
| |
|
|
|
|
|
| |
This fixes the initialisation functions when using -prof or
-finfo-table-map.
Fixes #21370
|
| | |
|
| |
|
|
|
|
| |
There was no mention of the changes to type-checking plugins
in the 9.4.1 notes, and the extending_ghc documentation contained
a reference to an outdated type.
|
| | |
|
| |
|
|
| |
This should fix #21352
|
| |
|
|
|
|
| |
This means cost centres and coverage ticks will still be present in
output. Makes using -dsuppress-all more convenient when looking at
profiled builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we deprecate the eventlogging RTS ways and instead enable eventlog
support in the remaining ways. This simplifies packaging and reduces GHC
compilation times (as we can eliminate two whole compilations of the RTS)
while simplifying the end-user story. The trade-off is a small increase
in binary sizes in the case that the user does not want eventlogging
support, but we think that this is a fine trade-off.
This also revealed a latent RTS bug: some files which included `Cmm.h`
also assumed that it defined various macros which were in fact defined
by `Config.h`, which `Cmm.h` did not include. Fixing this in turn
revealed that `StgMiscClosures.cmm` failed to import various spinlock
statistics counters, as evidenced by the failed unregisterised build.
Closes #18948.
|
| |
|
|
| |
If the user has not configured a writer then there is nothing to flush.
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #21373
|
| | |
|
| |
|
|
|
|
| |
We also disable the stage1 testing which is broken.
Related to #21072
|
| | |
|
| |
|
|
|
|
| |
It's quite nice we can do this by mostly deleting code
Fixes #21373
|
| | |
|
| |
|
|
|
|
|
|
| |
Here we introduce support into our command-line parsing infrastructure
and driver for handling gnu-style response file arguments,
typically used to work around platform command-line length limitations.
Fixes #16476.
|
| |
|
|
|
|
|
|
|
|
| |
We should only accept the type `Any` in foreign import/export
declarations when it has type `Type` or `UnliftedType`.
This patch adds a kind check, and a special error message triggered by
occurrences of `Any` in foreign import/export declarations at other
kinds.
Fixes #21305
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Solves the quadratic worst case performance of freeing megablocks that
was described in issue #19897.
During GC runs, we now keep a secondary free list for megablocks that is
neither sorted, nor coalesced. That way, free becomes an O(1) operation
at the expense of not being able to reuse memory for larger allocations.
At the end of a GC run, the secondary free list is sorted and then
merged into the actual free list in a single pass.
That way, our worst case performance is O(n log(n)) rather than O(n^2).
We postulate that temporarily losing coalescense during a single GC run
won't have any adverse effects in practice because:
- We would need to release enough memory during the GC, and then after
that (but within the same GC run) allocate a megablock group of more
than one megablock. This seems unlikely, as large objects are not
copied during GC, and so we shouldn't need such large allocations
during a GC run.
- Allocations of megablock groups of more than one megablock are rare.
They only happen when a single heap object is large enough to require
that amount of space. Any allocation areas that are supposed to hold
more than one heap object cannot use megablock groups, because only
the first megablock of a megablock group has valid `bdescr`s. Thus,
heap object can only start in the first megablock of a group, not in
later ones.
|
| |
|
|
| |
As suggested in #20733.
|
| | |
|
| | |
|
| |
|
|
| |
Also drops the unused TREC_COMMITTED transaction state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that @JunmingZhao42 and I noticed while working on her
MMTK port. Specifically, in stg_stop_thread we used stg_enter_info as a
sentinel at the tail of a stack after a thread has completed. However,
stg_enter_info expects to have a two-field payload, which we do not
push. Consequently, if the GC ends up somehow the stack it will attempt
to interpret data past the end of the stack as the frame's fields,
resulting in unsound behavior.
To fix this I eliminate this hacky use of `stg_stop_thread` and instead
introduce a new stack frame type, `stg_dead_thread_info`. Not only does
this eliminate the potential for the previously mentioned memory
unsoundness but it also more clearly captures the intended structure of
the dead threads' stacks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Drop libtool logic from gen-dll, allowing us to drop the remaining logic
from the `configure` script.
Strangely, this appears to reliably reduce compiler allocations of
T16875 on Windows.
Closes #18826.
Metric Decrease:
T16875
|
| |
|
|
|
| |
GHC no longers uses libtool for linking and therefore this is no longer
necessary.
|
| |
|
|
|
|
|
|
|
| |
Previously we supported building statically-linked executables using
libtool. However, this was dropped in
91262e75dd1d80f8f28a3922934ec7e59290e28c in favor of using ar/ranlib
directly. Consequently we can drop this logic.
Fixes #18826.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As described in Note [Wired-in exceptions are not CAFfy], a small set of
built-in exception closures get special treatment in the code generator,
being declared as non-CAFfy despite potentially containing CAF
references. The original intent of this treatment for the RTS to then
add StablePtrs for each of the closures, ensuring that they are not
GC'd. However, this logic was not applied consistently and eventually
removed entirely in 951c1fb0. This lead to #21141.
Here we fix this bug by reintroducing the StablePtrs and document the
status quo.
Closes #21141.
|
| | |
|
| |
|
|
|
|
|
| |
To ensure that the build benefits from Hadrian's usual logic for building
packages, avoiding #21409.
Closes #21409.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `test.mk` would try to determine whether the dynamic,
profiling, and vanilla library ways are available by searching for
`PrimOpWrappers.{,dyn_,p_}hi` in directory reported by `ghc-pkg field
ghc-prim library-dirs`. However, this is extremely fragile as
there is no guarantee that there is only one library directory. To
handle the case of multiple `library-dirs` correct we would
have to carry out the delicate task of tokenising the directory list (in
shell, no less).
Since this isn't a task that I am eager to solve, I have rather moved
the detection logic into the testsuite driver and instead perform a test
compilation in each of the ways. This should be more robust than the
previous approach.
I stumbled upon this while fixing #20579.
|
