| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to providing stack traces, the scary HasCallStack will
hopefully make people think whether they want to use these functions,
i.e. act as a documentation hint that something weird might happen.
A single metric increased, which doesn't visibly
use any method with `HasCallStack`.
-------------------------
Metric Decrease:
T9630
Metric Decrease:
T19695
T9630
-------------------------
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was not possible to refer to a data constructor using
InfixT with a dynamically bound name (i.e. a name with NameFlavour
`NameS` or `NameQ`) if a type constructor of the same
name exists.
This commit adds promoted counterparts to InfixT and UInfixT,
analogously to how PromotedT is the promoted counterpart to ConT.
Closes #20773
|
|
|
|
| |
Closes #20786
|
|
|
|
|
|
|
|
|
| |
As pointed out in #20776, placing quotes in this way linked to the
'Integral' type class which is nothing to do with 'readInt', the text
should rather just be "integral", to suggest that the argument must be
an integer.
Closes #20776
|
|
|
|
|
|
|
| |
Just a tiny cleanup inspired by the following comment:
https://gitlab.haskell.org/ghc/ghc/-/issues/19437#note_334271
I was just getting familiar with rts code base so I
thought might as well do this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the immediate problem that we hash the same file multiple
different times which causes quite a noticeably performance regression.
In the future we can probably do better than this by storing the
implementation hash in the interface file rather than dependending on
hashing the object file.
Related to #20604 which notes some inefficiencies with the current
recompilation logic.
Closes #20790
-------------------------
Metric Decrease:
T14052Type
-------------------------
|
|
|
|
|
|
| |
A separate issue is the fact that many of `hadrian`'s modules produce
`-Wincomplete-uni-patterns` warnings under 9.2, but that is probably best left
to a separate patch.
|
| |
|
|
|
|
|
| |
Previously, `-O1` and `-O2`, by way of their effect on the compilation
pipeline, they implicitly turned on constant folding
|
| |
|
|
|
|
|
|
|
| |
* Make 'mtimesDefault' use 'stimes' for the underlying monoid
rather than the default 'stimes'.
* Explain in the documentation why one might use `mtimesDefault`.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Amazing nobody had reported the "Foldabla" typo. :-(
The Traversable docs got overhauled, leaving a stale
link in Foldable to a section that got replaced. Gave
the new section an anchor and updated the link.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 806e49ae the package imports refactoring code was modified to rename
package imports. There was a small oversight which meant the code didn't
account for module visibility. This patch fixes that oversight.
In general the "lookupPackageName" function is unsafe to use as it
doesn't account for package visiblity/thinning/renaming etc, there is
just one use in the compiler which would be good to audit.
Fixes #20779
|
|
|
|
|
|
|
|
| |
Both tests import `Data.ByteString`, so the change in allocations is more or less expected.
Metric Increase:
T19695
T9630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Slight decrease but still noticeable on CI:
Baseline
Test Metric value New value Change
-----------------------------------------------------------------------------
ManyAlternatives(normal) ghc/alloc 747607676.0 747458936.0 -0.0%
ManyConstructors(normal) ghc/alloc 4003722296.0 4003530032.0 -0.0%
MultiLayerModules(normal) ghc/alloc 3064539560.0 3063984552.0 -0.0%
MultiLayerModulesRecomp(normal) ghc/alloc 894700016.0 894700624.0 +0.0%
PmSeriesG(normal) ghc/alloc 48410952.0 48262496.0 -0.3%
PmSeriesS(normal) ghc/alloc 61561848.0 61415768.0 -0.2%
PmSeriesT(normal) ghc/alloc 90975784.0 90829360.0 -0.2%
PmSeriesV(normal) ghc/alloc 60405424.0 60259008.0 -0.2%
T10421(normal) ghc/alloc 113275928.0 113137168.0 -0.1%
T10421a(normal) ghc/alloc 79195676.0 79050112.0 -0.2%
T10547(normal) ghc/alloc 28720176.0 28710008.0 -0.0%
T10858(normal) ghc/alloc 180992412.0 180857400.0 -0.1%
T11195(normal) ghc/alloc 283452220.0 283293832.0 -0.1%
T11276(normal) ghc/alloc 137882128.0 137745840.0 -0.1%
T11303b(normal) ghc/alloc 44453956.0 44309184.0 -0.3%
T11374(normal) ghc/alloc 248118668.0 247979880.0 -0.1%
T11545(normal) ghc/alloc 971994728.0 971852696.0 -0.0%
T11822(normal) ghc/alloc 131544864.0 131399024.0 -0.1%
T12150(optasm) ghc/alloc 79336468.0 79191888.0 -0.2%
T12227(normal) ghc/alloc 495064180.0 494943040.0 -0.0%
T12234(optasm) ghc/alloc 57198468.0 57053568.0 -0.3%
T12425(optasm) ghc/alloc 90928696.0 90793440.0 -0.1%
T12545(normal) ghc/alloc 1695417772.0 1695275744.0 -0.0%
T12707(normal) ghc/alloc 956258984.0 956138864.0 -0.0%
T13035(normal) ghc/alloc 102279484.0 102132616.0 -0.1%
T13056(optasm) ghc/alloc 367196556.0 367066408.0 -0.0%
T13253(normal) ghc/alloc 334365844.0 334255264.0 -0.0%
T13253-spj(normal) ghc/alloc 125474884.0 125328672.0 -0.1%
T13379(normal) ghc/alloc 359185604.0 359036960.0 -0.0%
T13701(normal) ghc/alloc 2403026480.0 2402677464.0 -0.0%
T13719(normal) ghc/alloc 4192234752.0 4192039448.0 -0.0%
T14052(ghci) ghc/alloc 2745868552.0 2747706176.0 +0.1%
T14052Type(ghci) ghc/alloc 7335937964.0 7336283280.0 +0.0%
T14683(normal) ghc/alloc 2992557736.0 2992436872.0 -0.0%
T14697(normal) ghc/alloc 363391248.0 363222920.0 -0.0%
T15164(normal) ghc/alloc 1292578008.0 1292434240.0 -0.0%
T15304(normal) ghc/alloc 1279603472.0 1279465944.0 -0.0%
T15630(normal) ghc/alloc 161707776.0 161602632.0 -0.1%
T16190(normal) ghc/alloc 276904644.0 276555264.0 -0.1%
T16577(normal) ghc/alloc 7573033016.0 7572982752.0 -0.0%
T16875(normal) ghc/alloc 34937980.0 34796592.0 -0.4%
T17096(normal) ghc/alloc 287436348.0 287299368.0 -0.0%
T17516(normal) ghc/alloc 1714727484.0 1714617664.0 -0.0%
T17836(normal) ghc/alloc 1091095748.0 1090958168.0 -0.0%
T17836b(normal) ghc/alloc 52467912.0 52321296.0 -0.3%
T17977(normal) ghc/alloc 44971660.0 44826480.0 -0.3%
T17977b(normal) ghc/alloc 40941128.0 40793160.0 -0.4%
T18140(normal) ghc/alloc 82363124.0 82213056.0 -0.2%
T18223(normal) ghc/alloc 1168448128.0 1168333624.0 -0.0%
T18282(normal) ghc/alloc 131577844.0 131440400.0 -0.1%
T18304(normal) ghc/alloc 86988664.0 86844432.0 -0.2%
T18478(normal) ghc/alloc 742992400.0 742871136.0 -0.0%
T18698a(normal) ghc/alloc 337654412.0 337526792.0 -0.0%
T18698b(normal) ghc/alloc 398840772.0 398716472.0 -0.0%
T18923(normal) ghc/alloc 68964992.0 68818768.0 -0.2%
T1969(normal) ghc/alloc 764285884.0 764156168.0 -0.0%
T19695(normal) ghc/alloc 1395577984.0 1395552552.0 -0.0%
T20049(normal) ghc/alloc 89159032.0 89012952.0 -0.2%
T3064(normal) ghc/alloc 191194856.0 191051816.0 -0.1%
T3294(normal) ghc/alloc 1604762016.0 1604656488.0 -0.0%
T4801(normal) ghc/alloc 296829368.0 296687824.0 -0.0%
T5030(normal) ghc/alloc 364720540.0 364580152.0 -0.0%
T5321FD(normal) ghc/alloc 271090004.0 270950824.0 -0.1%
T5321Fun(normal) ghc/alloc 301244320.0 301102960.0 -0.0%
T5631(normal) ghc/alloc 576154548.0 576022904.0 -0.0%
T5642(normal) ghc/alloc 471105876.0 470967552.0 -0.0%
T5837(normal) ghc/alloc 36328620.0 36186720.0 -0.4%
T6048(optasm) ghc/alloc 103125988.0 102981024.0 -0.1%
T783(normal) ghc/alloc 386945556.0 386795984.0 -0.0%
T9020(optasm) ghc/alloc 247835012.0 247696704.0 -0.1%
T9198(normal) ghc/alloc 47556208.0 47413784.0 -0.3%
T9233(normal) ghc/alloc 682210596.0 682069960.0 -0.0%
T9630(normal) ghc/alloc 1429689648.0 1429581168.0 -0.0%
T9675(optasm) ghc/alloc 431092812.0 430943192.0 -0.0%
T9872a(normal) ghc/alloc 1705052592.0 1705042064.0 -0.0%
T9872b(normal) ghc/alloc 2180406760.0 2180395784.0 -0.0%
T9872c(normal) ghc/alloc 1760508464.0 1760497936.0 -0.0%
T9872d(normal) ghc/alloc 501517968.0 501309464.0 -0.0%
T9961(normal) ghc/alloc 354037204.0 353891576.0 -0.0%
TcPlugin_RewritePerf(normal) ghc/alloc 2381708520.0 2381550824.0 -0.0%
WWRec(normal) ghc/alloc 589553520.0 589407216.0 -0.0%
hard_hole_fits(normal) ghc/alloc 492122188.0 492470648.0 +0.1%
hie002(normal) ghc/alloc 9336434800.0 9336443496.0 +0.0%
parsing001(normal) ghc/alloc 537680944.0 537659824.0 -0.0%
geo. mean -0.1%
|
|
|
|
|
|
| |
See #20725.
The commit includes source-code changes and a test case.
|
|
|
|
|
|
|
|
| |
`check-ppr` features an import of Data.List without an import list.
After 81082cf4, this breaks the local validate flavour because of the compat
warning and `-Werror`. So fix that.
Fixes #20789.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several times in the past, it has happened that things from GHC.Types
were not re-exported from GHC.Exts, forcing users to import either
GHC.Types or GHC.Prim, which are subject to internal change without
notice.
We now re-export GHC.Types from GHC.Exts, which should avoid this
happening again in the future.
In particular, we now re-export `Multiplicity` and `MultMul`,
which we didn't before.
Fixes #20695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser now accepts implicit parameters with higher-rank
types, such as
`foo :: (?ip :: forall a. a -> a) => ...`
Before this patch, we instead insisted on parentheses like so:
`foo :: (?ip :: (forall a. a -> a)) => ...`
The rest of the logic surrounding implicit parameters is unchanged;
in particular, even with ImpredicativeTypes, this idiom is not
likely to be very useful.
Fixes #20654
|
|
|
|
|
| |
Otherwise the user may be surprised by the missing context provided by
the latter.
|
|
|
|
|
|
|
|
|
|
| |
The amount of duplicated code in `mmapForLinker` hid the fact that some
codepaths would fail to update `mmap_32bit_base` (specifically, on
platforms like OpenBSD where `MAP_32BIT` is not supported).
Refactor the function to make the implementation more obviously correct.
Closes #20734.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
As noted in #20757, `GHC.SysTools.BaseDir.findToolDir` previously
contained an loop, which would be triggered in the case that the search
failed.
Closes #20757.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While a *strict* (i.e. constant space) right-fold on lists is not
possible, the default `foldr'` is optimised for structures like
`Seq`, that support efficient access to the right-most elements.
The original default implementation seems to have a better
constant factor for lists, so we add a monomorphic implementation
in GHC.List.
Should this be re-exported from `Data.List`? That would be a
user-visible change if both `Data.Foldable` and `Data.List` are
imported unqualified...
|
| |
|
|
|
|
|
|
|
| |
The geometric mean computation panicked when it was given
an empty list, which happens when there are no baselines.
Instead, we should simply return 1.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2.
This implements the first step in the plan formulated in #20025 to
improve the communication and migration strategy for the proposed
changes to Data.List.
Requires changing the haddock submodule to update the test output.
|
|
|
|
| |
comparison (#20088)
|
| |
|
|
|
|
|
|
|
|
| |
As noted in #19963, `realpath` is not specified by POSIX and therefore
cannot be assumed to be available. Here we provide a POSIX shell
implementation of `realpath`, due to Julian Ospald and others.
Closes #19963.
|
|
|
|
| |
These generally expect a particular word size.
|
|
|
|
|
|
|
| |
C11 rule 6.3.1.1 dictates that all small integers used in expressions be
implicitly converted to `signed int`. However, Cmm semantics require that the
width of the operands be preserved with zero-extension semantics. For
this reason we must recast sub-word arithmetic results as unsigned.
|
|
|
|
|
|
|
| |
As noted in Note [When in doubt, cast arguments as unsigned], we
must ensure that arguments have the correct signedness since some
operations (e.g. `%`) have different semantics depending upon
signedness.
|
|
|
|
|
| |
As noted in Note [Zero-extending sub-word signed results] we must
explicitly zero-extend the results of sub-word-sized signed operations.
|
|
|
|
|
| |
Under C's implicit widening rules, the result of an operation like (a >>
b) where a::Word8 and b::Word will have type Word, yet we want Word.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we rework the handling of sub-word operations in the AArch64
backend, fixing a number of bugs and inconsistencies. In short,
we now impose the invariant that all subword values are represented in
registers in zero-extended form. Signed arithmetic operations are then
responsible for sign-extending as necessary.
Possible future work:
* Use `CMP`s extended register form to avoid burning an instruction
in sign-extending the second operand.
* Track sign-extension state of registers to elide redundant sign
extensions in blocks with frequent sub-word signed arithmetic.
|
|
|
|
|
| |
This is necessary for lint-correctness since we no longer allow such
shifts in Cmm.
|
|
|
|
|
| |
We might be loading, e.g., a 16- or 8-bit value, in which case the
register width is not reflective of the loaded element size.
|
|
|
|
| |
There were found by the test-primops testsuite.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously primops.txt.pp stipulated that the word-size shift primops
were only defined for shift offsets in [0, word_size). However, there
was no further guidance for the definition of Cmm's sub-word size shift
MachOps.
Here we fix this by explicitly disallowing (checked in many cases by
CmmLint) shift operations where the shift offset is larger than the
shiftee. This is consistent with LLVM's shift operations, avoiding the
miscompilation noted in #20637.
|
|
|
|
|
| |
Previously we would emit the sign-extending LDS[HB] instructions for
sub-word loads. However, this is wrong, as noted in #20638.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the constant-folding behavior for MO_S_Quot and MO_S_Rem
failed to narrow its arguments, meaning that a program like:
%zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8))
would be miscompiled. Specifically, this program should reduce as
%lobits8(0x00e1::bits16) == -31
%quot(%lobits8(0x00e1::bits16), 3::bits8) == -10
%zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) == 246
However, with this bug the `%lobits8(0x00e1::bits16)` would instead
be treated as `+31`, resulting in the incorrect result of `75`.
(cherry picked from commit 94e197e3dbb9a48991eb90a03b51ea13d39ba4cc)
|
|
|
|
|
|
|
|
|
|
|
| |
Handle the case of a shift larger than the width of the shifted value.
This is necessary since x86 applies a mask of 0x1f to the shift amount,
meaning that, e.g., `shr 47, $eax` will actually shift by
47 & 0x1f == 15.
See #20626.
(cherry picked from commit 31370f1afe1e2f071b3569fb5ed4a115096127ca)
|
|
|
|
|
|
|
|
| |
FreeBSD (and likely NetBSD) /bin/sh does not support '>& word' to
redirect stdout + stderr. (Also the preferred syntax in bash would
be '&> word' to avoid surprises when `word` is "-" or a number).
Resolves: #20760
|