[Git][ghc/ghc][wip/hadrian-cross-stage2] 21 commits: Late plugins
Matthew Pickering (@mpickering)
gitlab at gitlab.haskell.org
Thu Dec 21 13:35:56 UTC 2023
Matthew Pickering pushed to branch wip/hadrian-cross-stage2 at Glasgow Haskell Compiler / GHC
Commits:
1c79526a by Finley McIlwaine at 2023-12-15T12:24:40-08:00
Late plugins
- - - - -
000c3302 by Finley McIlwaine at 2023-12-15T12:24:40-08:00
withTiming on LateCCs and late plugins
- - - - -
be4551ac by Finley McIlwaine at 2023-12-15T12:24:40-08:00
add test for late plugins
- - - - -
7c29da9f by Finley McIlwaine at 2023-12-15T12:24:40-08:00
Document late plugins
- - - - -
9a52ae46 by Ben Gamari at 2023-12-20T07:07:26-05:00
Fix thunk update ordering
Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.
However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:
Thread A Thread B
--------- ---------
t=0 Enter t
1 Push update frame
2 Begin evaluation
4 Pause thread
5 t.indirectee=tso
6 Release t.info=BLACKHOLE
7 ... (e.g. GC)
8 Resume thread
9 Finish evaluation
10 Relaxed t.indirectee=x
11 Load t.info
12 Acquire fence
13 Inspect t.indirectee
14 Release t.info=BLACKHOLE
Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.
Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.
We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.
See #23185.
- - - - -
f4b53538 by Vladislav Zavialov at 2023-12-20T07:08:02-05:00
docs: Fix link to 051-ghc-base-libraries.rst
The proposal is no longer available at the previous URL.
- - - - -
137f9a5b by Matthew Pickering at 2023-12-21T13:32:40+00:00
hadrian: Build all executables in bin/ folder
In the end the bindist creation logic copies them all into the bin
folder. There is no benefit to building a specific few binaries in the
lib/bin folder anymore.
This also removes the ad-hoc logic to copy the touchy and unlit
executables from stage0 into stage1. It takes <1s to build so we might
as well just build it.
- - - - -
8dbf8770 by Matthew Pickering at 2023-12-21T13:34:44+00:00
fail when bindist configure fails
- - - - -
b423d0ed by Matthew Pickering at 2023-12-21T13:34:44+00:00
Correctly propagate build/host/target to bindist
fix host/target bindist
t
- - - - -
3a8a7694 by Matthew Pickering at 2023-12-21T13:34:44+00:00
ci: Test cross bindists
- - - - -
b202c743 by Matthew Pickering at 2023-12-21T13:34:44+00:00
CROSS_STAGE variable
- - - - -
4f58274e by Matthew Pickering at 2023-12-21T13:34:44+00:00
Use explicit syntax rather than pure
- - - - -
2fdc889f by Matthew Pickering at 2023-12-21T13:34:44+00:00
ci: Javascript don't set CROSS_EMULATOR
There is no CROSS_EMULATOR needed to run javascript binaries, so we
don't set the CROSS_EMULATOR to some dummy value.
- - - - -
4ef11d5f by Matthew Pickering at 2023-12-21T13:34:44+00:00
hadrian: Fill in more of the default.host toolchain file
When you are building a cross compiler this file will be used to build
stage1 and it's libraries, so we need enough information here to work
accurately. There is still more work to be done (see for example, word
size is still fixed).
- - - - -
8f06a824 by Matthew Pickering at 2023-12-21T13:35:36+00:00
hadrian: Build stage 2 cross compilers
* Most of hadrian is abstracted over the stage in order to remove the
assumption that the target of all stages is the same platform. This
allows the RTS to be built for two different targets for example.
* Abstracts the bindist creation logic to allow building either normal
or cross bindists. Normal bindists use stage 1 libraries and a stage 2
compiler. Cross bindists use stage 2 libararies and a stage 2
compiler.
-------------------------
Metric Decrease:
T10421a
T10858
T11195
T11276
T11374
T11822
T15630
T17096
T18478
T20261
Metric Increase:
parsing001
-------------------------
- - - - -
43a67bd7 by GHC GitLab CI at 2023-12-21T13:35:39+00:00
fix
- - - - -
776eaf8c by GHC GitLab CI at 2023-12-21T13:35:39+00:00
Build genapply per stage
- - - - -
4a676565 by GHC GitLab CI at 2023-12-21T13:35:39+00:00
Correct GHC_PKG path
- - - - -
8eba7a0d by GHC GitLab CI at 2023-12-21T13:35:39+00:00
Don't build genapply for javascript backend
- - - - -
5efe5f6c by Matthew Pickering at 2023-12-21T13:35:39+00:00
hadrian: Make binary-dist-dir the default build target
This allows us to have the logic in one place about which
libraries/stages to build with cross compilers.
- - - - -
858431a1 by Matthew Pickering at 2023-12-21T13:35:39+00:00
Fix exe path
- - - - -
30 changed files:
- .gitlab/ci.sh
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/Core/LateCC.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Plugins.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/StgToCmm/Bind.hs
- configure.ac
- distrib/configure.ac.in
- docs/users_guide/9.10.1-notes.rst
- docs/users_guide/extending_ghc.rst
- hadrian/bindist/Makefile
- hadrian/bindist/config.mk.in
- hadrian/cfg/default.host.target.in
- hadrian/src/Builder.hs
- hadrian/src/Context.hs
- hadrian/src/Expression.hs
- hadrian/src/Flavour.hs
- hadrian/src/Flavour/Type.hs
- hadrian/src/Hadrian/Expression.hs
- hadrian/src/Hadrian/Haskell/Hash.hs
- hadrian/src/Hadrian/Oracles/TextFile.hs
- hadrian/src/Oracles/Flag.hs
- hadrian/src/Oracles/Flavour.hs
- hadrian/src/Oracles/Setting.hs
- hadrian/src/Oracles/TestSettings.hs
- hadrian/src/Packages.hs
- hadrian/src/Rules.hs
- hadrian/src/Rules/BinaryDist.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c4212be0c107b8a7c6eed558959a2882c353f337...858431a1a7b99422c9b109239aa0f0f418412aac
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c4212be0c107b8a7c6eed558959a2882c353f337...858431a1a7b99422c9b109239aa0f0f418412aac
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20231221/be0ac5db/attachment-0001.html>
More information about the ghc-commits
mailing list