[Git][ghc/ghc][wip/ghci-primcall] 13 commits: Revert "rts: Drop racy assertion"

Luite Stegeman (@luite) gitlab at gitlab.haskell.org
Fri Jan 13 07:44:49 UTC 2023



Luite Stegeman pushed to branch wip/ghci-primcall at Glasgow Haskell Compiler / GHC


Commits:
db11f358 by Ben Gamari at 2023-01-12T07:49:04-05:00
Revert "rts: Drop racy assertion"

The logic here was inverted. Reverting the commit to avoid confusion
when examining the commit history.

This reverts commit b3eacd64fb36724ed6c5d2d24a81211a161abef1.

- - - - -
3242139f by Ben Gamari at 2023-01-12T07:49:04-05:00
rts: Drop racy assertion

0e274c39bf836d5bb846f5fa08649c75f85326ac added an assertion in
`dirty_MUT_VAR` checking that the MUT_VAR being dirtied was clean.
However, this isn't necessarily the case since another thread may have
raced us to dirty the object.

- - - - -
9ffd5d57 by Ben Gamari at 2023-01-12T07:49:41-05:00
configure: Fix escaping of `$tooldir`

In !9547 I introduced `$tooldir` directories into GHC's default link and
compilation flags to ensure that our C toolchain finds its own headers
and libraries before others on the system. However, the patch was subtly
wrong in the escaping of `$tooldir`. Fix this.

Fixes #22561.

- - - - -
905d0b6e by Sebastian Graf at 2023-01-12T15:51:47-05:00
Fix contification with stable unfoldings (#22428)

Many functions now return a `TailUsageDetails` that adorns a `UsageDetails` with
a `JoinArity` that reflects the number of join point binders around the body
for which the `UsageDetails` was computed. `TailUsageDetails` is now returned by
`occAnalLamTail` as well as `occAnalUnfolding` and `occAnalRules`.

I adjusted `Note [Join points and unfoldings/rules]` and
`Note [Adjusting right-hand sides]` to account for the new machinery.
I also wrote a new `Note [Join arity prediction based on joinRhsArity]`
and refer to it when we combine `TailUsageDetails` for a recursive RHS.

I also renamed

  * `occAnalLam` to `occAnalLamTail`
  * `adjustRhsUsage` to `adjustTailUsage`
  * a few other less important functions

and properly documented the that each call of `occAnalLamTail` must pair up with
`adjustTailUsage`.

I removed `Note [Unfoldings and join points]` because it was redundant with
`Note [Occurrences in stable unfoldings]`.

While in town, I refactored `mkLoopBreakerNodes` so that it returns a condensed
`NodeDetails` called `SimpleNodeDetails`.

Fixes #22428.

The refactoring seems to have quite beneficial effect on ghc/alloc performance:

```
     CoOpt_Read(normal) ghc/alloc    784,778,420    768,091,176  -2.1% GOOD
         T12150(optasm) ghc/alloc     77,762,270     75,986,720  -2.3% GOOD
         T12425(optasm) ghc/alloc     85,740,186     84,641,712  -1.3% GOOD
         T13056(optasm) ghc/alloc    306,104,656    299,811,632  -2.1% GOOD
         T13253(normal) ghc/alloc    350,233,952    346,004,008  -1.2%
         T14683(normal) ghc/alloc  2,800,514,792  2,754,651,360  -1.6%
         T15304(normal) ghc/alloc  1,230,883,318  1,215,978,336  -1.2%
         T15630(normal) ghc/alloc    153,379,590    151,796,488  -1.0%
         T16577(normal) ghc/alloc  7,356,797,056  7,244,194,416  -1.5%
         T17516(normal) ghc/alloc  1,718,941,448  1,692,157,288  -1.6%
         T19695(normal) ghc/alloc  1,485,794,632  1,458,022,112  -1.9%
        T21839c(normal) ghc/alloc    437,562,314    431,295,896  -1.4% GOOD
        T21839r(normal) ghc/alloc    446,927,580    440,615,776  -1.4% GOOD

              geo. mean                                          -0.6%
              minimum                                            -2.4%
              maximum                                            -0.0%
```

Metric Decrease:
    CoOpt_Read
    T10421
    T12150
    T12425
    T13056
    T18698a
    T18698b
    T21839c
    T21839r
    T9961

- - - - -
a1491c87 by Andreas Klebinger at 2023-01-12T15:52:23-05:00
Only gc sparks locally when we can ensure marking is done.

When performing GC without work stealing there was no guarantee that
spark pruning was happening after marking of the sparks. This could
cause us to GC live sparks under certain circumstances.

Fixes #22528.

- - - - -
8acfe930 by Cheng Shao at 2023-01-12T15:53:00-05:00
Change MSYSTEM to CLANG64 uniformly

- - - - -
73bc162b by M Farkas-Dyck at 2023-01-12T15:53:42-05:00
Make `GHC.Tc.Errors.Reporter` take `NonEmpty ErrorItem` rather than `[ErrorItem]`, which lets us drop some panics.

Also use the `BasicMismatch` constructor rather than `mkBasicMismatchMsg`, which lets us drop the "-Wno-incomplete-record-updates" flag.

- - - - -
1b812b69 by Oleg Grenrus at 2023-01-12T15:54:21-05:00
Fix #22728: Not all diagnostics in safe check are fatal

Also add tests for the issue and -Winferred-safe-imports in general

- - - - -
c79b2b65 by Matthew Pickering at 2023-01-12T15:54:58-05:00
Don't run hadrian-multi on fast-ci label

Fixes #22667

- - - - -
9a3d6add by Bodigrim at 2023-01-13T00:46:36-05:00
Bump submodule bytestring to 0.11.4.0

Metric Decrease:
    T21839c
    T21839r

- - - - -
df33c13c by Ben Gamari at 2023-01-13T00:47:12-05:00
gitlab-ci: Bump Darwin bootstrap toolchain

This updates the bootstrap compiler on Darwin from 8.10.7 to 9.2.5,
ensuring that we have the fix for #21964.

- - - - -
756a66ec by Ben Gamari at 2023-01-13T00:47:12-05:00
gitlab-ci: Pass -w to cabal update

Due to cabal#8447, cabal-install 3.8.1.0 requires a compiler to run
`cabal update`.
- - - - -
d1b606d3 by Luite Stegeman at 2023-01-13T16:43:59+09:00
Add PrimCallConv support to GHCi

This adds support for calling Cmm code from bytecode using the native
calling convention, allowing modules that use `foreign import prim`
to be loaded and debugged in GHCi.

This patch introduces a new `PRIMCALL` bytecode instruction and
a helper stack frame `stg_primcall`. The code is based on the
existing functionality for dealing with unboxed tuples in bytecode,
which has been generalised to handle arbitrary calls.

Fixes #22051

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- .gitlab/darwin/nix/sources.json
- .gitlab/darwin/toolchain.nix
- .gitlab/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/ByteCode/Instr.hs
- compiler/GHC/ByteCode/Types.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Reg.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Data/Graph/Directed.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/StgToByteCode.hs
- compiler/GHC/StgToCmm/Foreign.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Utils/Misc.hs
- docs/users_guide/9.6.1-notes.rst
- libraries/bytestring
- m4/fp_settings.m4
- m4/ghc_convert_os.m4
- rts/Disassembler.c
- rts/Interpreter.c
- rts/RtsSymbols.c
- rts/Sparks.c
- rts/StgMiscClosures.cmm
- rts/include/rts/Bytecodes.h


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4c8f5e7ea1a59b88b79f64cd7a827414a134d137...d1b606d32d5182aa86fcf9e2f44138dc6ad8635d

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4c8f5e7ea1a59b88b79f64cd7a827414a134d137...d1b606d32d5182aa86fcf9e2f44138dc6ad8635d
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/20230113/3d833791/attachment.html>


More information about the ghc-commits mailing list