| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Move around datatypes, functions and instances that are GHC-specific out
of the `Language.Haskell.Syntax.*` modules to reduce the GHC
dependencies in them -- progressing towards #21592
Creates a module `Language.Haskell.Syntax.Basic` to hold basic
definitions required by the other L.H.S modules (and don't belong in any
of them)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ModuleName used to live in GHC.Unit.Module.Name. In this commit, the
definition of ModuleName and its associated functions are moved to
Language.Haskell.Syntax.Module.Name according to the current plan
towards making the AST GHC-independent.
The instances for ModuleName for Outputable, Uniquable and Binary were
moved to the module in which the class is defined because these instances
depend on GHC.
The instance of Eq for ModuleName is slightly changed to no longer
depend on unique explicitly and instead uses FastString's instance of
Eq.
|
| |
|
|
|
|
|
|
|
|
|
| |
Move the GHC-independent definitions from GHC.Hs.ImpExp to
Language.Haskell.Syntax.ImpExp with the required TTG extension fields
such as to keep the AST independent from GHC.
This is progress towards having the haskell-syntax package, as described
in #21592
Bumps haddock submodule
|
| |
|
|
| |
Bumps text and exceptions submodules due to bounds.
|
| |
|
|
|
|
|
|
|
| |
To 0.9.0 and 4.17.0 respectively.
Bumps array, deepseq, directory, filepath, haskeline, hpc, parsec, stm,
terminfo, text, unix, haddock, and hsc2hs submodules.
(cherry picked from commit ba47b95122b7b336ce1cc00896a47b584ad24095)
|
| |
|
|
|
|
|
|
|
| |
The call sites in `Driver.Main` are duplicative, but this is good,
because the next step is to remove `InteractiveContext` from `Core.Lint`
into `Core.Lint.Interactive`.
Also further clean up `Core.Lint` to use a better configuration record
than the one we initially added.
|
| |
|
|
| |
Co-Authored-By: Andre Marianiello <andremarianiello@users.noreply.github.com>
|
| |
|
|
|
|
| |
Finishes what !7467 (closed) started.
Progress towards #17957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As proposed in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7508#note_432877 and
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7508#note_434676,
`GHC.HsToCore.Ticks` is about ticks, breakpoints are separate and
backend-specific (only for the bytecode interpreter), and mix entry
writing is just for HPC.
With this split we separate out those interpreter- and HPC-specific
its, and keep the main `GHC.HsToCore.Ticks` agnostic.
Also, instead of passing the reversed list and count around, we use
`SizedSeq` which abstracts over the algorithm. This is much nicer to
avoid noise and prevents bugs.
(The bugs are not just hypothetical! I missed up the reverses on an
earlier draft of this commit.)
|
| |
|
|
|
|
| |
The old name made it confusing why disabling HPC didn't disable the
entire pass. The name makes it clear --- there are other reasons to add
ticks in addition.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
too hard
Progress towards #17957
Because of `CoreM`, I did not move the `DynFlags` and `HscEnv` to other
modules as thoroughly as I usually do. This does mean that risk of
`DynFlags` "creeping back in" is higher than it usually is.
After we do the same process to the other Core passes, and then figure
out what we want to do about `CoreM`, we can finish the job started
here.
That is a good deal more work, however, so it certainly makes sense to
land this now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two bugs which were adding dependencies on alex/happy when
building from a source dist.
* When we try to pass `--with-alex` and `--with-happy` to cabal when
configuring but the builders are not set. This is fixed by making them
optional.
* When we configure, cabal requires alex/happy because of the
build-tool-depends fields. These are now made optional with a cabal
flag (build-tool-depends) for compiler/hpc-bin/genprimopcode.
Fixes #21627
|
| |
|
|
|
|
| |
This is preliminary work for JavaScript support. It's better to put the
code handling the desugaring of Prim, C and JavaScript declarations into
separate modules.
|
| |
|
|
| |
We want `DynFlags` only mentioned in `GHC.Driver`.
|
| |
|
|
| |
Progress towards #17957
|
| |
|
|
|
| |
Metric Decrease:
T16875
|
| |
|
|
| |
Progress towards #17957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, `Backend` becomes an abstract type
(there are no more exposed value constructors).
Decisions that were formerly made by asking "is the
current back end equal to (or different from) this named value
constructor?" are now made by interrogating the back end about
its properties, which are functions exported by `GHC.Driver.Backend`.
There is a description of how to migrate code using `Backend` in the
user guide.
Clients using the GHC API can find a backdoor to access the Backend
datatype in GHC.Driver.Backend.Internal.
Bumps haddock submodule.
Fixes #20927
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit adds module `GHC.Cmm.Dominators`, which provides a wrapper
around two existing algorithms in GHC: the Lengauer-Tarjan dominator
analysis from the X86 back end and the reverse postorder ordering from
the Cmm Dataflow framework. Issue #20726 proposes that we evaluate
some alternatives for dominator analysis, but for the time being, the
best path forward is simply to use the existing analysis on
`CmmGraph`s.
This commit addresses a bullet in #21200.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LlvmConfig contains information read from llvm-passes and llvm-targets
files in GHC's top directory. Reading these files is done only when
needed (i.e. when the LLVM backend is used) and cached for the whole
compiler session. This patch changes the way this is done:
- Split LlvmConfig into LlvmConfig and LlvmConfigCache
- Store LlvmConfigCache in HscEnv instead of DynFlags: there is no
good reason to store it in DynFlags. As it is fixed per session, we
store it in the session state instead (HscEnv).
- Initializing LlvmConfigCache required some changes to driver functions
such as newHscEnv. I've used the opportunity to untangle initHscEnv
from initGhcMonad (in top-level GHC module) and to move it to
GHC.Driver.Main, close to newHscEnv.
- I've also made `cmmPipeline` independent of HscEnv in order to remove
the call to newHscEnv in regalloc_unit_tests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC uses global initializers for a number of things including
cost-center registration, info-table provenance registration, and setup
of foreign exports. Previously, the global initializer arrays which
referenced these initializers would live in the object file of the C
stub, which would then be merged into the main object file of the
module.
Unfortunately, this approach is no longer tenable with the move to
Clang/LLVM on Windows (see #21019). Specifically, lld's PE backend does
not support object merging (that is, the -r flag). Instead we are now
rather packaging a module's object files into a static library. However,
this is problematic in the case of initializers as there are no
references to the C stub object in the archive, meaning that the linker
may drop the object from the final link.
This patch refactors our handling of global initializers to instead
place initializer arrays within the object file of the module to which
they belong. We do this by introducing a Cmm data declaration containing
the initializer array in the module's Cmm stream. While the initializer
functions themselves remain in separate C stub objects, the reference
from the module's object ensures that they are not dropped from the
final link.
In service of #21068.
|
| |
|
|
|
|
|
|
| |
- Factorize Tidy options into TidyOpts datatype. Initialize it in
GHC.Driver.Config.Tidy
- Same thing for StaticPtrOpts
- Perform lookups of unpackCString[Utf8]# once in initStaticPtrOpts
instead of for every use of mkStringExprWithFS
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Names appearing in Haddock docstrings are lexed and renamed like any other names
appearing in the AST. We currently rename names irrespective of the namespace,
so both type and constructor names corresponding to an identifier will appear in
the docstring. Haddock will select a given name as the link destination based on
its own heuristics.
This patch also restricts the limitation of `-haddock` being incompatible with
`Opt_KeepRawTokenStream`.
The export and documenation structure is now computed in GHC and serialised in
.hi files. This can be used by haddock to directly generate doc pages without
reparsing or renaming the source. At the moment the operation of haddock
is not modified, that's left to a future patch.
Updates the haddock submodule with the minimum changes needed.
|
| |
|
|
|
|
|
|
|
|
| |
* Users can define their own (~) type operator
* Haddock can display documentation for the built-in (~)
* New transitional warnings implemented:
-Wtype-equality-out-of-scope
-Wtype-equality-requires-operators
Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As `Note [Demand analysis for recursive data constructors]` describes, we now
refrain from unboxing recursive data type arguments, for two reasons:
1. Relating to run/alloc perf: Similar to
`Note [CPR for recursive data constructors]`, it seldomly improves run/alloc
performance if we just unbox a finite number of layers of a potentially huge
data structure.
2. Relating to ghc/alloc perf: Inductive definitions on single-product
recursive data types like the one in T11545 will (diverge, and) have very
deep demand signatures before any other abortion mechanism in Demand
analysis is triggered. That leads to great and unnecessary churn on Demand
analysis when ultimately we will never make use of any nested strictness
information anyway.
Conclusion: Discard nested demand and boxity information on such recursive types
with the help of `Note [Detecting recursive data constructors]`.
I also implemented `GHC.Types.Unique.MemoFun.memoiseUniqueFun` in order to avoid
the overhead of repeated calls to `GHC.Core.Opt.WorkWrap.Utils.isRecDataCon`.
It's nice and simple and guards against some smaller regressions in T9233 and
T16577.
ghc/alloc performance-wise, this patch is a very clear win:
Test Metric value New value Change
---------------------------------------------------------------------------------------
LargeRecord(normal) ghc/alloc 6,141,071,720 6,099,871,216 -0.7%
MultiLayerModulesTH_OneShot(normal) ghc/alloc 2,740,973,040 2,705,146,640 -1.3%
T11545(normal) ghc/alloc 945,475,492 85,768,928 -90.9% GOOD
T13056(optasm) ghc/alloc 370,245,880 326,980,632 -11.7% GOOD
T18304(normal) ghc/alloc 90,933,944 76,998,064 -15.3% GOOD
T9872a(normal) ghc/alloc 1,800,576,840 1,792,348,760 -0.5%
T9872b(normal) ghc/alloc 2,086,492,432 2,073,991,848 -0.6%
T9872c(normal) ghc/alloc 1,750,491,240 1,737,797,832 -0.7%
TcPlugin_RewritePerf(normal) ghc/alloc 2,286,813,400 2,270,957,896 -0.7%
geo. mean -2.9%
No noteworthy change in run/alloc either.
NoFib results show slight wins, too:
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
constraints -1.9% -1.4%
fasta -3.6% -2.7%
reverse-complem -0.3% -0.9%
treejoin -0.0% -0.3%
--------------------------------------------------------------------------------
Min -3.6% -2.7%
Max +0.1% +0.1%
Geometric Mean -0.1% -0.1%
Metric Decrease:
T11545
T13056
T18304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows ghc and its dependencies to be built using a normal
invocation of cabal-install. Each componenent which relied on generated
files or additional configuration now has a Setup.hs file.
There are also various fixes to the cabal files to satisfy
cabal-install.
There is a new hadrian command which will build a stage2 compiler and
then a stage3 compiler by using cabal.
```
./hadrian/build build-cabal
```
There is also a new CI job which tests running this command.
For the 9.4 release we will upload all the dependent executables to
hackage and then end users will be free to build GHC and GHC executables
via cabal.
There are still some unresolved questions about how to ensure soundness
when loading plugins into a reinstalled GHC (#20742) which will be
tighted up in due course.
Fixes #19896
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does three major things:
* Enforce the invariant that all strict fields must contain tagged
pointers.
* Try to predict the tag on bindings in order to omit tag checks.
* Allows functions to pass arguments unlifted (call-by-value).
The former is "simply" achieved by wrapping any constructor allocations with
a case which will evaluate the respective strict bindings.
The prediction is done by a new data flow analysis based on the STG
representation of a program. This also helps us to avoid generating
redudant cases for the above invariant.
StrictWorkers are created by W/W directly and SpecConstr indirectly.
See the Note [Strict Worker Ids]
Other minor changes:
* Add StgUtil module containing a few functions needed by, but
not specific to the tag analysis.
-------------------------
Metric Decrease:
T12545
T18698b
T18140
T18923
LargeRecord
Metric Increase:
LargeRecord
ManyAlternatives
ManyConstructors
T10421
T12425
T12707
T13035
T13056
T13253
T13253-spj
T13379
T15164
T18282
T18304
T18698a
T1969
T20049
T3294
T4801
T5321FD
T5321Fun
T783
T9233
T9675
T9961
T19695
WWRec
-------------------------
|
| |
|
|
|
| |
This allows cost centres to be inserted after the core optimization
pipeline has run.
|
| |
|
|
|
| |
Also derive some more instances. GHC doesn't need them, but downstream
consumers may need to e.g. put stuff in maps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we introduce a new data structure, RoughMap, inspired by the
previous `RoughTc` matching mechanism for checking instance matches.
This allows [Fam]InstEnv to be implemented as a trie indexed by these
RoughTc signatures, reducing the complexity of instance lookup and
FamInstEnv merging (done during the family instance conflict test)
from O(n) to O(log n).
The critical performance improvement currently realised by this patch is
in instance matching. In particular the RoughMap mechanism allows us to
discount many potential instances which will never match for constraints
involving type variables (see Note [Matching a RoughMap]). In realistic
code bases matchInstEnv was accounting for 50% of typechecker time due
to redundant work checking instances when simplifying instance contexts
when deriving instances. With this patch the cost is significantly
reduced.
The larger constants in InstEnv creation do mean that a few small
tests regress in allocations slightly. However, the runtime of T19703 is
reduced by a factor of 4. Moreover, the compilation time of the Cabal
library is slightly improved.
A couple of test cases are included which demonstrate significant
improvements in compile time with this patch.
This unfortunately does not fix the testcase provided in #19703 but does
fix #20933
-------------------------
Metric Decrease:
T12425
Metric Increase:
T13719
T9872a
T9872d
hard_hole_fits
-------------------------
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
This allows us to remove the dependency on parsec and hence transitively
on text.
Also added some simple unit tests for the parser and fixed two small
issues in the documentation.
Fixes #21033
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StgToCmm: add Config, remove CgInfoDownwards
StgToCmm: runC api change to take StgToCmmConfig
StgToCmm: CgInfoDownad -> StgToCmmConfig
StgToCmm.Monad: update getters/setters/withers
StgToCmm: remove CallOpts in StgToCmm.Closure
StgToCmm: remove dynflag references
StgToCmm: PtrOpts removed
StgToCmm: add TMap to config, Prof - dynflags
StgToCmm: add omit yields to config
StgToCmm.ExtCode: remove redundant import
StgToCmm.Heap: remove references to dynflags
StgToCmm: codeGen api change, DynFlags -> Config
StgToCmm: remove dynflags in Env and StgToCmm
StgToCmm.DataCon: remove dynflags references
StgToCmm: remove dynflag references in DataCon
StgToCmm: add backend avx flags to config
StgToCmm.Prim: remove dynflag references
StgToCmm.Expr: remove dynflag references
StgToCmm.Bind: remove references to dynflags
StgToCmm: move DoAlignSanitisation to Cmm.Type
StgToCmm: remove PtrOpts in Cmm.Parser.y
DynFlags: update ipInitCode api
StgToCmm: Config Module is single source of truth
StgToCmm: Lazy config breaks IORef deadlock
testsuite: bump countdeps threshold
StgToCmm.Config: strictify fields except UpdFrame
Strictifying UpdFrameOffset causes the RTS build with stage1 to
deadlock. Additionally, before the deadlock performance of the RTS
is noticeably slower.
StgToCmm.Config: add field descriptions
StgToCmm: revert strictify on Module in config
testsuite: update CountDeps tests
StgToCmm: update comment, fix exports
Specifically update comment about loopification passed into dynflags
then stored into stgToCmmConfig. And remove getDynFlags from
Monad.hs exports
Types.Name: add pprFullName function
StgToCmm.Ticky: use pprFullname, fixup ExtCode imports
Cmm.Info: revert cmmGetClosureType removal
StgToCmm.Bind: use pprFullName, Config update comments
StgToCmm: update closureDescription api
StgToCmm: SAT altHeapCheck
StgToCmm: default render for Info table, ticky
Use default rendering contexts for info table and ticky ticky, which should be independent of command line input.
testsuite: bump count deps
pprFullName: flag for ticky vs normal style output
convertInfoProvMap: remove unused parameter
StgToCmm.Config: add backend flags to config
StgToCmm.Config: remove Backend from Config
StgToCmm.Prim: refactor Backend call sites
StgToCmm.Prim: remove redundant imports
StgToCmm.Config: refactor vec compatibility check
StgToCmm.Config: add allowQuotRem2 flag
StgToCmm.Ticky: print internal names with parens
StgToCmm.Bind: dispatch ppr based on externality
StgToCmm: Add pprTickyname, Fix ticky naming
Accidently removed the ctx for ticky SDoc output. The only relevant flag
is sdocPprDebug which was accidental set to False due to using
defaultSDocContext without altering the flag.
StgToCmm: remove stateful fields in config
fixup: config: remove redundant imports
StgToCmm: move Sequel type to its own module
StgToCmm: proliferate getCallMethod updated api
StgToCmm.Monad: add FCodeState to Monad Api
StgToCmm: add second reader monad to FCode
fixup: Prim.hs: missed a merge conflict
fixup: Match countDeps tests to HEAD
StgToCmm.Monad: withState -> withCgState
To disambiguate it from mtl withState. This withState shouldn't be
returning the new state as a value. However, fixing this means tackling
the knot tying in CgState and so is very difficult since it changes when
the thunk of the knot is forced which either leads to deadlock or to
compiler panic.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeOutput: LCGConfig, add handshake initLCGConfig
Add two modules:
GHC.CmmToLlvm.Config -- to hold the Llvm code gen config
GHC.Driver.Config.CmmToLlvm -- for initialization, other utils
CmmToLlvm: remove HasDynFlags, add LlvmConfig
CmmToLlvm: add lcgContext to LCGConfig
CmmToLlvm.Base: DynFlags --> LCGConfig
Llvm: absorb LlvmOpts into LCGConfig
CmmToLlvm.Ppr: swap DynFlags --> LCGConfig
CmmToLlvm.CodeGen: swap DynFlags --> LCGConfig
CmmToLlvm.CodeGen: swap DynFlags --> LCGConfig
CmmToLlvm.Data: swap LlvmOpts --> LCGConfig
CmmToLlvm: swap DynFlags --> LCGConfig
CmmToLlvm: move LlvmVersion to CmmToLlvm.Config
Additionally:
- refactor Config and initConfig to hold LlvmVersion
- push IO needed to get LlvmVersion to boundary between Cmm and LLvm
code generation
- remove redundant imports, this is much cleaner!
CmmToLlvm.Config: store platformMisc_llvmTarget
instead of all of platformMisc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would traverse the STG AST twice looking for free variables.
* Once in `annTopBindingsDeps` which considers top level and imported ids free.
Its output is used to put bindings in dependency order. The pass happens
in STG pipeline.
* Once in `annTopBindingsFreeVars` which only considers non-top level ids free.
Its output is used by the code generator to compute offsets into closures.
This happens in Cmm (CodeGen) pipeline.
Now these two traversal operations are merged into one - `FVs.depSortWithAnnotStgPgm`.
The pass happens right at the end of STG pipeline. Some type signatures had to be
updated due to slight shifts of StgPass boundaries (for example, top-level CodeGen
handler now directly works with CodeGen flavoured Stg AST instead of Vanilla).
Due to changed order of bindings, a few debugger type reconstruction bugs
have resurfaced again (see tests break018, break021) - work item #18004 tracks this
investigation.
authors: simonpj, nineonine
|
| |
|
|
|
| |
As GHC has become target agnostic, we've left behind some now-useless
logic in both build systems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Primops types were dependent on the target word-size at *compiler*
compilation time. It's an issue for multi-target as GHC may not have the
correct primops types for the target.
This patch fixes some primops types: if they take or return fixed 64-bit
values they now always use `Int64#/Word64#`, even on 64-bit
architectures (where they used `Int#/Word#` before). Users of these
primops may now need to convert from Int64#/Word64# to Int#/Word# (a
no-op at runtime).
This is a stripped down version of !3658 which goes the all way of
changing the underlying primitive types of Word64/Int64. This is left
for future work.
T12545 allocations increase ~4% on some CI platforms and decrease ~3% on
AArch64.
Metric Increase:
T12545
Metric Decrease:
T12545
|
| |
|
|
|
|
|
|
|
| |
We should strive to make our includes in terms of the RTS as much as
possible. One place there that is not possible, the llvm version, we
make a new tiny header
Stage numbers are somewhat arbitrary, if we simple need a newer RTS, we
should say so.
|
| |
|
|
| |
This is necessary to use reexported-modules
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the following find and replace:
- `rts/dist` -> `rts/dist-install` # for paths
- `rts_dist` -> `rts_dist-install` # for make rules and vars
- `,dist` -> `,dist-install` # for make, just in rts/ghc.mk`
Why do this? Does it matter when the RTS is just built once? The answer
is, yes, I think it does, because I want the distdir--stage
correspondence to be consistent.
In particular, for #17191 and continuing from
d5de970dafd5876ef30601697576167f56b9c132 I am going to make the headers
(`rts/includes`) increasingly the responsibility of the RTS (hence their
new location). However, those headers are current made for multiple
stages. This will probably become unnecessary as work on #17191
progresses and the compiler proper becomes more of a freestanding cabal
package (e.g. a library that can be downloaded from Hackage and built
without any autoconf). However, until that is finished, we have will
transitional period where the RTS and headers need to agree on dirs for
multiple stages.
I know the make build system is going away, but it's not going yet, so I
need to change it to unblock things :).
|
| |
|
|
|
|
|
|
|
| |
Use an (Raw)PkgQual datatype instead of `Maybe FastString` to represent
package imports. Factorize the code that renames RawPkgQual into PkgQual
in function `rnPkgQual`. Renaming consists in checking if the FastString
is the magic "this" keyword, the home-unit unit-id or something else.
Bump haddock submodule
|
