| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We noticed that the structure of CoreUnfolding could leave double the
amount of CoreExprs which were retained in the situation where the
template but not all the predicates were forced. This observation was
then confirmed using ghc-debug:
```
(["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 237)
(["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1)
(["ghc:GHC.Core:Case","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 12)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 1)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 78)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","ghc-prim:GHC.Types:False","THUNK_1_0"],Count 1)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 3)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0"],Count 1)
(["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 31)
(["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 4307)
(["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 6)
(["ghc:GHC.Core:Let","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 29)
(["ghc:GHC.Core:Lit","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1)
(["ghc:GHC.Core:Tick","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 36)
(["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 1)
(["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 6)
(["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","ghc-prim:GHC.Types:True","THUNK_1_0"],Count 2)
```
Where we can see that the first argument is forced but there are still
thunks remaining which retain the old expr.
For my test case (a very big module, peak of 3 000 000 core terms) this
reduced peak memory usage by 1G (12G -> 11G).
Fixes #20905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test only wants 1000 descriptors, so changing the limit to double
that *in the context of just this test* makes no sense.
This is a manual revert of 8f7194fae23bdc6db72fc5784933f50310ce51f9.
The justification given in the description doesn't instill confidence.
As of HEAD, the test fails on OpenBSD where ulimit -n is hard-limited
to 1024. The test suite attempts to change it to 2048, which
fails. The test proceeds with the unchanged default of 512 and
naturally the test program fails due to the low ulimit. The fixed test
now passes.
|
| |
|
|
|
|
|
|
|
|
| |
Use primOpId instead of mkPrimOpId in a few places to benefit from
Id caching.
I had to mess a little bit with the module hierarchy to fix cycles and
to avoid adding too many new dependencies to count-deps tests.
|
|
|
|
|
|
| |
SmallArray doesn't perform bounds check (faster).
Make primop tags start at 0 to avoid index arithmetic.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When quoting (using a TH single or double quote) a built-in
name such as the list constructor (:), we didn't always check
that the resulting 'Name' was in the correct namespace.
This patch adds a check in GHC.Rename.Splice to ensure
we get a Name that is in the term-level/type-level namespace,
when using a single/double tick, respectively.
Fixes #20884.
|
| |
|
|
|
|
| |
Issue #18045 got fixed by !6971.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The test now passes on OpenBSD instead of generating broken source
which was rejected by GHC with
ManyAlternatives.hs:5:1: error:
The type signature for ‘f’ lacks an accompanying binding
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The user's guide failed to explicitly mention that GADTSyntax
can be used to declare newtypes, so we add an example and a couple
of explanations.
Also explains that `-XGADTs` generalises `-XExistentialQuantification`.
Fixes #20848 and #20865.
|
|
|
|
|
|
|
|
| |
Function `lookupIPE` does not modify its argument. Reflect this in the
type. Module `CloneStack.c` relies on this for RTS without tables
next to code.
Fixes #20879
|
|
|
|
| |
Closes #20874
|
|
|
|
| |
This yields a small, but measurable, performance improvement.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.
Public Interface
~~~~~~~~~~~~~~~~
In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.
```
ghc -unit @unitLibCore -unit @unitLib
```
where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.
```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```
The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.
```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```
Then when the compiler starts in --make mode it will compile both units lib and lib-core.
There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.
Options used when working with Multiple Home Units
There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.
-working-dir ⟨dir⟩
It is common to assume that a package is compiled in the directory
where its cabal file resides. Thus, all paths used in the compiler
are assumed to be relative to this directory. When there are
multiple home units the compiler is often not operating in the
standard directory and instead where the cabal.project file is
located. In this case the -working-dir option can be passed which
specifies the path from the current directory to the directory the
unit assumes to be it’s root, normally the directory which contains
the cabal file.
When the flag is passed, any relative paths used by the compiler are
offset by the working directory. Notably this includes -i and
-I⟨dir⟩ flags.
-this-package-name ⟨name⟩
This flag papers over the awkward interaction of the PackageImports
and multiple home units. When using PackageImports you can specify
the name of the package in an import to disambiguate between modules
which appear in multiple packages with the same name.
This flag allows a home unit to be given a package name so that you
can also disambiguate between multiple home units which provide
modules with the same name.
-hidden-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules in a home unit should not be visible outside of the unit it
belongs to.
The main use of this flag is to be able to recreate the difference
between an exposed and hidden module for installed packages.
-reexported-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules are not defined in a unit but should be reexported. The
effect is that other units will see this module as if it was defined
in this unit.
The use of this flag is to be able to replicate the reexported
modules feature of packages with multiple home units.
Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.
For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.
```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )
foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```
> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.
A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.
Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For tools or libraries using the API there is one very important closure
property which must be adhered to:
> Any dependency which is not a home unit must not (transitively) depend
on a home unit.
For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.
If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.
Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a few limitations of the initial implementation which will be smoothed out on user demand.
* Package thinning/renaming syntax is not supported
* More complicated reexports/renaming are not yet supported.
* It’s more common to run into existing linker bugs when loading a
large number of packages in a session (for example #20674, #20689)
* Backpack is not yet supported when using multiple home units.
* Dependency chasing can be quite slow with a large number of
modules and packages.
* Loading wired-in packages as home units is currently not supported
(this only really affects GHC developers attempting to load
template-haskell).
* Barely any normal GHCi features are supported, it would be good to
support enough for ghcid to work correctly.
Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.
Internal Changes
~~~~~~~~~~~~~~~~
* The biggest change is that the HomePackageTable is replaced with the
HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
which contains information specific to each home unit.
* The HomeUnitEnv contains:
- A unit state, each home unit can have different package db flags
- A set of dynflags, each home unit can have different flags
- A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
place the linking step into the build plan so linking can proceed in
parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
determined by looking at the value of the node. In order to achieve
this, downsweep now performs a more complete job of downsweeping and
then the dependenices are recorded forever in the node rather than
being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
of the existing API code which is unit agnostic (for example, in the
driver).
The road may be bumpy for a little while after this change but the
basics are well-tested.
One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.
Closes #10827
-------------------------
Metric Increase:
MultiLayerModules
-------------------------
Co-authored-by: Fendor <power.walross@gmail.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completes the fix for #20779 / !7123.
Beforehand, the program worked by accident because the two versions of
the library happened to be ordered properly (due to how the hashes were
computed). In the real world I observed them being the other way around
which meant the final lookup failed because we weren't filtering for
visibility.
I modified the test so that it failed (and it's fixed by this patch).
|
|
|
|
| |
Fixes #20854
|
|
|
|
| |
See ticket #20852
|
|
|
|
|
|
|
|
|
|
| |
If you specify PERF_BASELINE_COMMIT then this can fail if the specific
commit you selected didn't have perf test metrics. (This can happen in
CI for example if a build fails on master).
Therefore instead of just reporting all tests as new, we start searching
downwards from this point to try and find a good commit to report
numbers from.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reqlib modifer was supposed to indicate that a test needed a certain
library in order to work. If the library happened to be installed then
the test would run as normal.
However, CI has never run these tests as the packages have not been
installed and we don't want out tests to depend on things which might
get externally broken by updating the compiler.
The new strategy is to run these tests in head.hackage, where the tests
have been cabalised as well as possible. Some tests couldn't be
transferred into the normal style testsuite but it's better than never
running any of the reqlib tests. https://gitlab.haskell.org/ghc/head.hackage/-/merge_requests/169
A few submodules also had reqlib tests and have been updated to remove
it.
Closes #16264 #20032 #17764 #16561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A declaration such as
infixr ++++
is supplied with an implicit fixity of 9 in the parser, but uses
an invalid SrcSpan to capture this. Use of this span triggers a panic.
Fix the problem by not recording an exact print annotation for the
non-existent fixity source.
Closes #20846
|
|
|
|
|
| |
I made a mistake in the bash script so there were errors about
"$CI_MERGE_REQUEST_DIFF_BASE_SHA" not existing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add files GHC.Cmm.Config, GHC.Driver.Config.Cmm
Cmm: DynFlag references --> CmmConfig
Cmm.Pipeline: reorder imports, add handshake
Cmm: DynFlag references --> CmmConfig
Cmm.Pipeline: DynFlag references --> CmmConfig
Cmm.LayoutStack: DynFlag references -> CmmConfig
Cmm.Info.Build: DynFlag references -> CmmConfig
Cmm.Config: use profile to retrieve platform
Cmm.CLabel: unpack NCGConfig in labelDynamic
Cmm.Config: reduce CmmConfig surface area
Cmm.Config: add cmmDoCmmSwitchPlans field
Cmm.Config: correct cmmDoCmmSwitchPlans flag
The original implementation dispatches work in cmmImplementSwitchPlans
in an `otherwise` branch, hence we must add a not to correctly dispatch
Cmm.Config: add cmmSplitProcPoints simplify Config
remove cmmBackend, and cmmPosInd
Cmm.CmmToAsm: move ncgLabelDynamic to CmmToAsm
Cmm.CLabel: remove cmmLabelDynamic function
Cmm.Config: rename cmmOptDoLinting -> cmmDoLinting
testsuite: update CountDepsAst CountDepsParser
|
| |
|
|
|
|
|
| |
OpenBSD doesn't have this library and so the linker complains:
ld.lld: error: unable to find library -ldl
|
|
|
|
|
|
|
|
| |
This is not entirely accurate because some openbsd architectures use
gcc. Yet we don't have ghc ported to them and thus the approximation
is good enough.
Fixes ghcilink006 test
|
|
|
|
|
|
|
|
|
|
|
|
| |
Plugins were directly fetched from HscEnv (hsc_static_plugins and
hsc_plugins). The tight coupling of plugins and of HscEnv is undesirable
and it's better to store them in a new Plugins datatype and to use it in
the plugins' API (e.g. withPlugins, mapPlugins...).
In the process, the interactive context (used by GHCi) got proper
support for different static plugins than those used for loaded modules.
Bump haddock submodule
|
|
|
|
|
|
| |
As suggested in #20601, this is a short-hand for enabling the usual
GHC-internal sanity checks one typically leans on when debugging runtime
crashes.
|
|
|
|
| |
As noted in #20601, the previous name was rather misleading.
|
| |
|
|
|
|
|
|
|
| |
Here we introduce code generator support for instrument array primops
with bounds checking, enabled with the `-fcheck-prim-bounds` flag.
Introduced to debug #20769.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This place ensures that the default -dcore-lint option is disabled by
default when collect_compiler_stats is used but you can still pass
-dcore-lint as an additional option (see T1969 which tests core lint
performance).
Fixes #20830
-------------------------
Metric Decrease:
PmSeriesS
PmSeriesT
PmSeriesV
T10858
T11195
T11276
T11374
T11822
T14052
T14052Type
T17096
T17836
T17836b
T18478
T18698a
T18698b
-------------------------
|
|
|
|
| |
Extracted from !6622
|
|
|
|
|
|
| |
Fixes #20827 by filtering out any default free variable demands (as per
`defaultFvDmd`) prior to comparing the assocs of the `DmdEnv`.
The details are in `Note [Demand type Equality]`.
|
|
|
|
|
|
|
| |
With this patch, withBinBuffer will construct a ByteString that
properly captures the reference to the BinHandle internal
MutableByteArray#, making it safe to convert a BinHandle to ByteString
and use that ByteString outside the continuation.
|
|
|
|
| |
Fixes #20812
|
|
|
|
| |
Fixes #20543
|
|
|
|
| |
Closes #20189
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out there was already a function in the CI script to correctly
set the baseline for performance tests but it was just never called. I
now call it during the initialisation to set the correct baseline.
I also made the make testsuite driver take into account the
PERF_BASELINE_COMMIT environment variable
Fixes #20811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow specialization for the ok_app predicate.
Perf improvements:
Baseline
Test Metric value New value Change
-----------------------------------------------------------------------------
ManyAlternatives(normal) ghc/alloc 747317244.0 746444024.0 -0.1%
ManyConstructors(normal) ghc/alloc 4005046448.0 4001548792.0 -0.1%
MultiLayerModules(normal) ghc/alloc 3063361000.0 3063178472.0 -0.0%
MultiLayerModulesRecomp(normal) ghc/alloc 894208428.0 894252496.0 +0.0%
PmSeriesG(normal) ghc/alloc 48021692.0 47901592.0 -0.3%
PmSeriesS(normal) ghc/alloc 61322504.0 61149008.0 -0.3%
PmSeriesT(normal) ghc/alloc 90879364.0 90609048.0 -0.3%
PmSeriesV(normal) ghc/alloc 60155376.0 59983632.0 -0.3%
T10421(normal) ghc/alloc 112820720.0 112517208.0 -0.3%
T10421a(normal) ghc/alloc 78783696.0 78557896.0 -0.3%
T10547(normal) ghc/alloc 28331984.0 28354160.0 +0.1%
T10858(normal) ghc/alloc 180715296.0 180226720.0 -0.3%
T11195(normal) ghc/alloc 284139184.0 283981048.0 -0.1%
T11276(normal) ghc/alloc 137830804.0 137688912.0 -0.1%
T11303b(normal) ghc/alloc 44080856.0 43956152.0 -0.3%
T11374(normal) ghc/alloc 249319644.0 249059288.0 -0.1%
T11545(normal) ghc/alloc 971507488.0 971146136.0 -0.0%
T11822(normal) ghc/alloc 131410208.0 131269664.0 -0.1%
T12150(optasm) ghc/alloc 78866860.0 78762296.0 -0.1%
T12227(normal) ghc/alloc 494467900.0 494138112.0 -0.1%
T12234(optasm) ghc/alloc 56781044.0 56588256.0 -0.3%
T12425(optasm) ghc/alloc 90462264.0 90240272.0 -0.2%
T12545(normal) ghc/alloc 1694316588.0 1694128448.0 -0.0%
T12707(normal) ghc/alloc 955665168.0 955005336.0 -0.1%
T13035(normal) ghc/alloc 101875160.0 101713312.0 -0.2%
T13056(optasm) ghc/alloc 366370168.0 365347632.0 -0.3%
T13253(normal) ghc/alloc 333741472.0 332612920.0 -0.3%
T13253-spj(normal) ghc/alloc 124947560.0 124427552.0 -0.4%
T13379(normal) ghc/alloc 358997996.0 358879840.0 -0.0%
T13701(normal) ghc/alloc 2400391456.0 2399956840.0 -0.0%
T13719(normal) ghc/alloc 4193179228.0 4192476392.0 -0.0%
T14052(ghci) ghc/alloc 2734741552.0 2735731808.0 +0.0%
T14052Type(ghci) ghc/alloc 7323235724.0 7323042264.0 -0.0%
T14683(normal) ghc/alloc 2990457260.0 2988899144.0 -0.1%
T14697(normal) ghc/alloc 363606476.0 363452952.0 -0.0%
T15164(normal) ghc/alloc 1291321780.0 1289491968.0 -0.1%
T15304(normal) ghc/alloc 1277838020.0 1276208304.0 -0.1%
T15630(normal) ghc/alloc 161074632.0 160388136.0 -0.4%
T16190(normal) ghc/alloc 276567192.0 276235216.0 -0.1%
T16577(normal) ghc/alloc 7564318656.0 7535598656.0 -0.4%
T16875(normal) ghc/alloc 34867720.0 34752440.0 -0.3%
T17096(normal) ghc/alloc 288477360.0 288156960.0 -0.1%
T17516(normal) ghc/alloc 1712777224.0 1704655496.0 -0.5%
T17836(normal) ghc/alloc 1092127336.0 1091709880.0 -0.0%
T17836b(normal) ghc/alloc 52083516.0 51954056.0 -0.2%
T17977(normal) ghc/alloc 44552228.0 44425448.0 -0.3%
T17977b(normal) ghc/alloc 40540252.0 40416856.0 -0.3%
T18140(normal) ghc/alloc 81908200.0 81678928.0 -0.3%
T18223(normal) ghc/alloc 1166459176.0 1164418104.0 -0.2%
T18282(normal) ghc/alloc 131123648.0 130740432.0 -0.3%
T18304(normal) ghc/alloc 86486796.0 86223088.0 -0.3%
T18478(normal) ghc/alloc 746029440.0 745619968.0 -0.1%
T18698a(normal) ghc/alloc 337037580.0 336533824.0 -0.1%
T18698b(normal) ghc/alloc 398324600.0 397696400.0 -0.2%
T18923(normal) ghc/alloc 68496432.0 68286264.0 -0.3%
T1969(normal) ghc/alloc 760424696.0 759641664.0 -0.1%
T19695(normal) ghc/alloc 1421672472.0 1413682104.0 -0.6%
T20049(normal) ghc/alloc 88601524.0 88336560.0 -0.3%
T3064(normal) ghc/alloc 190808832.0 190659328.0 -0.1%
T3294(normal) ghc/alloc 1604483120.0 1604339080.0 -0.0%
T4801(normal) ghc/alloc 296501624.0 296388448.0 -0.0%
T5030(normal) ghc/alloc 364336308.0 364206240.0 -0.0%
T5321FD(normal) ghc/alloc 270688492.0 270386832.0 -0.1%
T5321Fun(normal) ghc/alloc 300860396.0 300559200.0 -0.1%
T5631(normal) ghc/alloc 575822760.0 575579160.0 -0.0%
T5642(normal) ghc/alloc 470243356.0 468988784.0 -0.3%
T5837(normal) ghc/alloc 35936468.0 35821360.0 -0.3%
T6048(optasm) ghc/alloc 102587024.0 102222000.0 -0.4%
T783(normal) ghc/alloc 386539204.0 386003344.0 -0.1%
T9020(optasm) ghc/alloc 247435312.0 247324184.0 -0.0%
T9198(normal) ghc/alloc 47170036.0 47054840.0 -0.2%
T9233(normal) ghc/alloc 677186820.0 676550032.0 -0.1%
T9630(normal) ghc/alloc 1456411516.0 1451045736.0 -0.4%
T9675(optasm) ghc/alloc 427190224.0 426812568.0 -0.1%
T9872a(normal) ghc/alloc 1704660040.0 1704681856.0 +0.0%
T9872b(normal) ghc/alloc 2180109488.0 2180130856.0 +0.0%
T9872c(normal) ghc/alloc 1760209640.0 1760231456.0 +0.0%
T9872d(normal) ghc/alloc 501126052.0 500973488.0 -0.0%
T9961(normal) ghc/alloc 353244688.0 353063104.0 -0.1%
TcPlugin_RewritePerf(normal) ghc/alloc 2387276808.0 2387254168.0 -0.0%
WWRec(normal) ghc/alloc 588651140.0 587684704.0 -0.2%
hard_hole_fits(normal) ghc/alloc 492063812.0 491798360.0 -0.1%
hie002(normal) ghc/alloc 9334355960.0 9334396872.0 +0.0%
parsing001(normal) ghc/alloc 537410584.0 537421736.0 +0.0%
geo. mean -0.2%
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in #20763 the way the stats were printed was quite hard for a
human to compare. Therefore we now insert the comma separator so that
they are easier to compare at a glance.
Before:
```
Baseline
Test Metric value New value Change
-----------------------------------------------------------------------------
Conversions(normal) run/alloc 107088.0 107088.0 +0.0%
DeriveNull(normal) run/alloc 112050656.0 112050656.0 +0.0%
InlineArrayAlloc(normal) run/alloc 1600040712.0 1600040712.0 +0.0%
InlineByteArrayAlloc(normal) run/alloc 1440040712.0 1440040712.0 +0.0%
InlineCloneArrayAlloc(normal) run/alloc 1600040872.0 1600040872.0 +0.0%
MethSharing(normal) run/alloc 480097864.0 480097864.0 +0.0%
T10359(normal) run/alloc 354344.0 354344.0 +0.0%
```
After
```
Baseline
Test Metric value New value Change
----------------------------------------------------------------------------------
Conversions(normal) run/alloc 107,088 107,088 +0.0%
DeriveNull(normal) run/alloc 112,050,656 112,050,656 +0.0%
InlineArrayAlloc(normal) run/alloc 1,600,040,712 1,600,040,712 +0.0%
InlineByteArrayAlloc(normal) run/alloc 1,440,040,712 1,440,040,712 +0.0%
InlineCloneArrayAlloc(normal) run/alloc 1,600,040,872 1,600,040,872 +0.0%
MethSharing(normal) run/alloc 480,097,864 480,097,864 +0.0%
T10359(normal) run/alloc 354,344 354,344 +0.0%
```
Closes #20763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isUnliftedTyCon was used in three places: Ticky, Template Haskell
and FFI checks.
It was straightforward to remove it from Ticky and Template Haskell.
It is now used in FFI only and renamed to marshalablePrimTyCon.
Previously, it was fetching information from a field
in PrimTyCon called is_unlifted. Instead, I've changed the code
to compute liftedness based on the kind.
isFFITy and legalFFITyCon are removed. They were only referred from
an old comment that I removed.
There were three functions to define a PrimTyCon, but the only difference
was that they were setting is_unlifted to True or False.
Everything is now done in mkPrimTyCon.
I also added missing integer types in Ticky.hs, I think it was an oversight.
Fixes #20401
|
|
|
|
| |
We use the parser generated by stack to ensure reproducibility
|
| |
|