[Git][ghc/ghc][wip/ghc-internals-move] 31 commits: Make decomposeRuleLhs a bit more clever
Matthew Pickering (@mpickering)
gitlab at gitlab.haskell.org
Mon Feb 5 12:23:44 UTC 2024
Matthew Pickering pushed to branch wip/ghc-internals-move at Glasgow Haskell Compiler / GHC
Commits:
ca2e919e by Simon Peyton Jones at 2024-01-31T09:29:45+00:00
Make decomposeRuleLhs a bit more clever
This fixes #24370 by making decomposeRuleLhs undertand
dictionary /functions/ as well as plain /dictionaries/
- - - - -
94ce031d by Teo Camarasu at 2024-02-01T05:49:49-05:00
doc: Add -Dn flag to user guide
Resolves #24394
- - - - -
31553b11 by Ben Gamari at 2024-02-01T12:21:29-05:00
cmm: Introduce MO_RelaxedRead
In hand-written Cmm it can sometimes be necessary to atomically load
from memory deep within an expression (e.g. see the `CHECK_GC` macro).
This MachOp provides a convenient way to do so without breaking the
expression into multiple statements.
- - - - -
0785cf81 by Ben Gamari at 2024-02-01T12:21:29-05:00
codeGen: Use relaxed accesses in ticky bumping
- - - - -
be423dda by Ben Gamari at 2024-02-01T12:21:29-05:00
base: use atomic write when updating timer manager
- - - - -
8a310e35 by Ben Gamari at 2024-02-01T12:21:29-05:00
Use relaxed atomics to manipulate TSO status fields
- - - - -
d6809ee4 by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Add necessary barriers when manipulating TSO owner
- - - - -
39e3ac5d by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Use `switch` to branch on why_blocked
This is a semantics-preserving refactoring.
- - - - -
515eb33d by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix synchronization on thread blocking state
We now use a release barrier whenever we update a thread's blocking
state. This required widening StgTSO.why_blocked as AArch64 does not
support atomic writes on 16-bit values.
- - - - -
eb38812e by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix data race in threadPaused
This only affects an assertion in the debug RTS and only needs relaxed
ordering.
- - - - -
26c48dd6 by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix data race in threadStatus#
- - - - -
6af43ab4 by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix data race in Interpreter's preemption check
- - - - -
9502ad3c by Ben Gamari at 2024-02-01T12:21:29-05:00
rts/Messages: Fix data race
- - - - -
60802db5 by Ben Gamari at 2024-02-01T12:21:30-05:00
rts/Prof: Fix data race
- - - - -
ef8ccef5 by Ben Gamari at 2024-02-01T12:21:30-05:00
rts: Use relaxed ordering on dirty/clean info tables updates
When changing the dirty/clean state of a mutable object we needn't have
any particular ordering.
- - - - -
76fe2b75 by Ben Gamari at 2024-02-01T12:21:30-05:00
codeGen: Use relaxed-read in closureInfoPtr
- - - - -
a6316eb4 by Ben Gamari at 2024-02-01T12:21:30-05:00
STM: Use acquire loads when possible
Full sequential consistency is not needed here.
- - - - -
6bddfd3d by Ben Gamari at 2024-02-01T12:21:30-05:00
rts: Use fence rather than redundant load
Previously we would use an atomic load to ensure acquire ordering.
However, we now have `ACQUIRE_FENCE_ON`, which allows us to express this
more directly.
- - - - -
55c65dbc by Ben Gamari at 2024-02-01T12:21:30-05:00
rts: Fix data races in profiling timer
- - - - -
856b5e75 by Ben Gamari at 2024-02-01T12:21:30-05:00
Add Note [C11 memory model]
- - - - -
6534da24 by Cheng Shao at 2024-02-01T12:22:07-05:00
compiler: move generic cmm optimization logic in NCG to a standalone module
This commit moves GHC.CmmToAsm.cmmToCmm to a standalone module,
GHC.Cmm.GenericOpt. The main motivation is enabling this logic to be
run in the wasm backend NCG code, which is defined in other modules
that's imported by GHC.CmmToAsm, causing a cyclic dependency issue.
- - - - -
87e34888 by Cheng Shao at 2024-02-01T12:22:07-05:00
compiler: explicitly disable PIC in wasm32 NCG
This commit explicitly disables the ncgPIC flag for the wasm32 target.
The wasm backend doesn't support PIC for the time being.
- - - - -
c6ce242e by Cheng Shao at 2024-02-01T12:22:07-05:00
compiler: enable generic cmm optimizations in wasm backend NCG
This commit enables the generic cmm optimizations in other NCGs to be
run in the wasm backend as well, followed by a late cmm control-flow
optimization pass. The added optimizations do catch some corner cases
not handled by the pre-NCG cmm pipeline and are useful in generating
smaller CFGs.
- - - - -
151dda4e by Andrei Borzenkov at 2024-02-01T12:22:43-05:00
Namespacing for WARNING/DEPRECATED pragmas (#24396)
New syntax for WARNING and DEPRECATED pragmas was added,
namely namespace specifierss:
namespace_spec ::= 'type' | 'data' | {- empty -}
warning ::= warning_category namespace_spec namelist strings
deprecation ::= namespace_spec namelist strings
A new data type was introduced to represent these namespace specifiers:
data NamespaceSpecifier =
NoSpecifier |
TypeNamespaceSpecifier (EpToken "type") |
DataNamespaceSpecifier (EpToken "data")
Extension field XWarning now contains this NamespaceSpecifier.
lookupBindGroupOcc function was changed: it now takes NamespaceSpecifier
and checks that the namespace of the found names matches the passed flag.
With this change {-# WARNING data D "..." #-} pragma will only affect value
namespace and {-# WARNING type D "..." #-} will only affect type
namespace. The same logic is applicable to DEPRECATED pragmas.
Finding duplicated warnings inside rnSrcWarnDecls now takes into
consideration NamespaceSpecifier flag to allow warnings with the
same names that refer to different namespaces.
- - - - -
38c3afb6 by Bryan Richter at 2024-02-01T12:23:19-05:00
CI: Disable the test-cabal-reinstall job
Fixes #24363
- - - - -
27020458 by Matthew Craven at 2024-02-03T01:53:26-05:00
Bump bytestring submodule to something closer to 0.12.1
...mostly so that 16d6b7e835ffdcf9b894e79f933dd52348dedd0c
(which reworks unaligned writes in Builder) and the stuff in
https://github.com/haskell/bytestring/pull/631 can see wider testing.
The less-terrible code for unaligned writes used in Builder on
hosts not known to be ulaigned-friendly also takes less effort
for GHC to compile, resulting in a metric decrease for T21839c
on some platforms.
The metric increase on T21839r is caused by the unrelated commit
750dac33465e7b59100698a330b44de7049a345c. It perhaps warrants
further analysis and discussion (see #23822) but is not critical.
Metric Decrease:
T21839c
Metric Increase:
T21839r
- - - - -
cdddeb0f by Rodrigo Mesquita at 2024-02-03T01:54:02-05:00
Work around autotools setting C11 standard in CC/CXX
In autoconf >=2.70, C11 is set by default for $CC and $CXX via the
-std=...11 flag. In this patch, we split the "-std" flag out of the $CC
and $CXX variables, which we traditionally assume to be just the
executable name/path, and move it to $CFLAGS/$CXXFLAGS instead.
Fixes #24324
- - - - -
5ff7cc26 by Apoorv Ingle at 2024-02-03T13:14:46-06:00
Expand `do` blocks right before typechecking using the `HsExpansion` philosophy.
- Fixes #18324 #20020 #23147 #22788 #15598 #22086 #21206
- The change is detailed in
- Note [Expanding HsDo with HsExpansion] in `GHC.Tc.Gen.Do`
- Note [Doing HsExpansion in the Renamer vs Typechecker] in `GHC.Rename.Expr`
expains the rational of doing expansions in type checker as opposed to in the renamer
- Adds new datatypes:
- `GHC.Hs.Expr.XXExprGhcRn`: new datatype makes this expansion work easier
1. Expansion bits for Expressions, Statements and Patterns in (`ExpandedThingRn`)
2. `PopErrCtxt` a special GhcRn Phase only artifcat to pop the previous error message in the error context stack
- `GHC.Basic.Origin` now tracks the reason for expansion in case of Generated
This is useful for type checking cf. `GHC.Tc.Gen.Expr.tcExpr` case for `HsLam`
- Kills `HsExpansion` and `HsExpanded` as we have inlined them in `XXExprGhcRn` and `XXExprGhcTc`
- Ensures warnings such as
1. Pattern match checks
2. Failable patterns
3. non-() return in body statements are preserved
- Kill `HsMatchCtxt` in favor of `TcMatchAltChecker`
- Testcases:
* T18324 T20020 T23147 T22788 T15598 T22086
* T23147b (error message check),
* DoubleMatch (match inside a match for pmc check)
* pattern-fails (check pattern match with non-refutable pattern, eg. newtype)
* Simple-rec (rec statements inside do statment)
* T22788 (code snippet from #22788)
* DoExpanion1 (Error messages for body statments)
* DoExpansion2 (Error messages for bind statements)
* DoExpansion3 (Error messages for let statements)
Also repoint haddock to the right submodule so that the test (haddockHypsrcTest) pass
Metric Increase 'compile_time/bytes allocated':
T9020
The testcase is a pathalogical example of a `do`-block with many statements that do nothing.
Given that we are expanding the statements into function binds, we will have to bear
a (small) 2% cost upfront in the compiler to unroll the statements.
- - - - -
0df8ce27 by Vladislav Zavialov at 2024-02-04T03:55:14-05:00
Reduce parser allocations in allocateCommentsP
In the most common case, the comment queue is empty, so we can skip the
work of processing it. This reduces allocations by about 10% in the
parsing001 test.
Metric Decrease:
MultiLayerModulesRecomp
parsing001
- - - - -
f74d2b35 by Ben Gamari at 2024-02-05T09:51:32+00:00
base: Cleanup whitespace in cbits
- - - - -
97671727 by Ben Gamari at 2024-02-05T12:23:10+00:00
Move `base` to `ghc-internal`
Here we move a good deal of the implementation of `base` into a new
package, `ghc-internal` such that it can be evolved independently
from the user-visible interfaces of `base`.
While we want to isolate implementation from interfaces, naturally, we
would like to avoid turning `base` into a mere set of module re-exports.
However, this is a non-trivial undertaking for a variety of reasons:
* `base` contains numerous known-key and wired-in things, requiring
corresponding changes in the compiler
* `base` contains a significant amount of C code and corresponding
autoconf logic, which is very fragile and difficult to break apart
* `base` has numerous import cycles, which are currently dealt with via
carefully balanced `hs-boot` files
* We must not break existing users
To accomplish this migration, I tried the following approaches:
* [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental
migration of modules into ghc-internal: this knot is simply too
intertwined to be easily pulled apart, especially given the rather
tricky import cycles that it contains)
* [Move-Core]: Moving the "core" connected component of base (roughly
150 modules) into ghc-internal. While the Haskell side of this seems
tractable, the C dependencies are very subtle to break apart.
* [Move-Incrementally]:
1. Move all of base into ghc-internal
2. Examine the module structure and begin moving obvious modules (e.g.
leaves of the import graph) back into base
3. Examine the modules remaining in ghc-internal, refactor as necessary
to facilitate further moves
4. Go to (2) iterate until the cost/benefit of further moves is
insufficient to justify continuing
5. Rename the modules moved into ghc-internal to ensure that they don't
overlap with those in base
6. For each module moved into ghc-internal, add a shim module to base
with the declarations which should be exposed and any requisite
Haddocks (thus guaranteeing that base will be insulated from changes
in the export lists of modules in ghc-internal
Here I am using the [Move-Incrementally] approach, which is empirically
the least painful of the unpleasant options above
Bumps haddock submodule.
Metric Decrease:
haddock.Cabal
haddock.base
Metric Increase:
MultiComponentModulesRecomp
T16875
- - - - -
30 changed files:
- .gitignore
- .gitlab-ci.yml
- compiler/GHC.hs
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Cmm/Expr.hs
- + compiler/GHC/Cmm/GenericOpt.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/Wasm.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/Driver/Config/CmmToAsm.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Match.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a0957e78de551caf859b3ef7ea51b21f9697ae25...9767172774688ecd50736a197215aab8573eb282
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a0957e78de551caf859b3ef7ea51b21f9697ae25...9767172774688ecd50736a197215aab8573eb282
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/20240205/3eec0427/attachment-0001.html>
More information about the ghc-commits
mailing list