[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 17 commits: base: Propagate `error` CallStack to thrown exception
Marge Bot (@marge-bot)
gitlab at gitlab.haskell.org
Fri Sep 20 12:24:26 UTC 2024
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
163b63ed by Ben Gamari at 2024-09-20T08:23:57-04:00
base: Propagate `error` CallStack to thrown exception
Previously `errorCallWithCallStackException` failed to propagate its
`CallStack` argument, which represents the call-chain of the preceding
`error` call, to the exception that it returned. Consequently, the
call-stack of `error` calls were quite useless.
Unfortunately, this is the second time that I have fixed this but it
seems the first must have been lost in rebasing.
Fixes #24807.
- - - - -
98e79c68 by Matthew Pickering at 2024-09-20T08:23:57-04:00
ci: Run abi-test on test-abi label
- - - - -
67a8356a by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
testsuite: Add a test for object determinism
Extends the abi_test with an object determinism check
Also includes a standalone test to be run by developers manually when
debugging issues with determinism.
- - - - -
38185b4f by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
determinism: Sampling uniques in the CG
To achieve object determinism, the passes processing Cmm and the rest of
the code generation pipeline musn't create new uniques which are
non-deterministic.
This commit changes occurrences of non-deterministic unique sampling
within these code generation passes by a deterministic unique sampling
strategy by propagating and threading through a deterministic
incrementing counter in them. The threading is done implicitly with
`UniqDSM` and `UniqDSMT`.
Secondly, the `DUniqSupply` used to run a `UniqDSM` must be threaded
through all passes to guarantee uniques in different passes are unique
amongst them altogether. Specifically, the same `DUniqSupply` must be
threaded through the CG Streaming pipeline, starting with Driver.Main
calling `StgToCmm.codeGen`, `cmmPipeline`, `cmmToRawCmm`, and
`codeOutput` in sequence.
To thread resources through the `Stream` abstraction, we use the `UniqDSMT`
transformer on top of `IO` as the Monad underlying the Stream. `UniqDSMT` will
thread the `DUniqSupply` through every pass applied to the `Stream`, for every
element. We use @type CgStream = Stream (UniqDSMT IO)@ for the Stream used in
code generation which that carries through the deterministic unique supply.
See Note [Deterministic Uniques in the CG]
- - - - -
6ca5b05d by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
determinism: Cmm unique renaming pass
To achieve object determinism, we need to prevent the non-deterministic
uniques from leaking into the object code. We can do this by
deterministically renaming the non-external uniques in the Cmm groups
that are yielded right after StgToCmm.
The key to deterministic renaming is observing that the order of
declarations, instructions, and data in the Cmm groups are already
deterministic (modulo other determinism bugs), regardless of the
uniques. We traverse the Cmm AST in this deterministic order and
rename the uniques, incrementally, in the order they are found, thus
making them deterministic. This renaming is guarded by
-fobject-determinism which is disabled by default for now.
This is one of the key passes for object determinism. Read about the
overview of object determinism and a more detailed explanation of this
pass in:
* Note [Object determinism]
* Note [Renaming uniques deterministically]
Significantly closes the gap to #12935
- - - - -
be5c4aa3 by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
determinism: DCmmGroup vs CmmGroup
Part of our strategy in producing deterministic objects, namely,
renaming all Cmm uniques in order, depend on the object code produced
having a deterministic order (say, A_closure always comes before
B_closure).
However, the use of LabelMaps in the Cmm representation invalidated this
requirement because the LabelMaps elements would already be in a
non-deterministic order (due to the original uniques), and the renaming
in sequence wouldn't work because of that non-deterministic order.
Therefore, we now start off with lists in CmmGroup (which preserve the
original order), and convert them into LabelMaps (for performance in the
code generator) after the uniques of the list elements have been
renamed.
See Note [DCmmGroup vs CmmGroup or: Deterministic Info Tables] and #12935.
Co-authored-by: Matthew Pickering <matthewtpickering at gmail.com>
- - - - -
1f54463a by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
determinism: Don't print unique in pprFullName
This unique was leaking as part of the profiling description in info
tables when profiling was enabled, despite not providing information
relevant to the profile.
- - - - -
8a2c862a by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
determinism: UDFM for distinct-constructor-tables
In order to produce deterministic objects when compiling with
-distinct-constructor-tables, we also have to update the data
constructor map to be backed by a deterministic unique map (UDFM) rather
than a non-deterministic one (UniqMap).
- - - - -
577c7dee by Rodrigo Mesquita at 2024-09-20T08:23:57-04:00
determinism: InfoTableMap uniques in generateCgIPEStub
Fixes object determinism when using -finfo-table-map
Make sure to also deterministically rename the IPE map (as per Note
[Renaming uniques deterministically]), and to use a deterministic unique
supply when creating new labels for the IPE information to guarantee
deterministic objects when IPE information is requested.
Note that the Cmm group produced in generateCgIPEStub must /not/ be
renamed because renaming uniques is not idempotent, and the references
to the previously renamed code in the IPE Cmm group would be renamed
twice and become invalid references to non-existent symbols.
We do need to det-rename the InfoTableMap that is created in the
conversion from Core to Stg. This is not a problem since that map won't
refer any already renamed names (since it was created before the
renaming).
- - - - -
7c0c11bc by doyougnu at 2024-09-20T08:23:58-04:00
linker: add --optimistic-linking flag
This patch adds:
- the --optimistic-linking flag which binds unknown symbols in the
runtime linker to 0xDEADBEEF instead of exiting with failure
- The test T25240 which tests these flags using dead code in the FFI system.
- closes #25240
This patch is part of the upstreaming haskell.nix patches project.
- - - - -
4125dfd0 by Ryan Hendrickson at 2024-09-20T08:23:59-04:00
compiler: Use type abstractions when deriving
For deriving newtype and deriving via, in order to bring type variables
needed for the coercions into scope, GHC generates type signatures for
derived class methods. As a simplification, drop the type signatures and
instead use type abstractions to bring method type variables into scope.
- - - - -
d45db125 by Zubin Duggal at 2024-09-20T08:24:00-04:00
driver: Ensure we run driverPlugin for staticPlugins (#25217)
driverPlugins are only run when the plugin state changes. This meant they were
never run for static plugins, as their state never changes.
We need to keep track of whether a static plugin has been initialised to ensure
we run static driver plugins at least once. This necessitates an additional field
in the `StaticPlugin` constructor as this state has to be bundled with the plugin
itself, as static plugins have no name/identifier we can use to otherwise reference
them
- - - - -
5924515d by Andreas Klebinger at 2024-09-20T08:24:01-04:00
Allow unknown fd device types for setNonBlockingMode.
This allows fds with a unknown device type to have blocking mode
set. This happens for example for fds from the inotify subsystem.
Fixes #25199.
- - - - -
bf31f6ad by Sylvain Henry at 2024-09-20T08:24:13-04:00
Enum deriving: reuse predError, succError, toEnumError
Reuse predError, succError, and toEnumError when deriving Enum instances
to avoid generating different error strings per instance. E.g. before
this patch for every instance for a type FOO we would generate a string:
"pred{FOO}: tried to take `pred' of first tag in enumeration"#
- - - - -
2d7b4db4 by Sylvain Henry at 2024-09-20T08:24:13-04:00
Enum deriving: generate better code (#16364)
Generate better code for Enum.toEnum: check both the lower and the upper
bounds at once with an unsigned comparison.
Initially I've used a type ascription with a call to 'fromIntegral',
hence the slight refactoring of nlAscribe. Using 'fromIntegral' was
problematic (too low in the module hierarchy) so 'enumIntToWord' was
introduced instead.
Combined with the previous commit, T21839c ghc/alloc decrease by 5%
Metric Decrease:
T21839c
- - - - -
bfc246a6 by Sven Tennie at 2024-09-20T08:24:14-04:00
ghc-toolchain: Set -fuse-ld even for ld.bfd
This reflects the behaviour of the autoconf scripts.
- - - - -
60db6c25 by Sylvain Henry at 2024-09-20T08:24:17-04:00
Parser: be more careful when lexing extended literals (#25258)
Previously we would lex invalid prefixes like "8#Int3" as [8#Int, 3].
A side-effect of this patch is that we now allow negative unsigned
extended literals. They trigger an overflow warning later anyway.
- - - - -
30 changed files:
- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/BlockId.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Dataflow.hs
- compiler/GHC/Cmm/Dataflow/Graph.hs
- compiler/GHC/Cmm/Graph.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/Info/Build.hs
- compiler/GHC/Cmm/LayoutStack.hs
- compiler/GHC/Cmm/Opt.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Pipeline.hs
- compiler/GHC/Cmm/ProcPoint.hs
- compiler/GHC/Cmm/Reducibility.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Switch.hs
- compiler/GHC/Cmm/Switch/Implement.hs
- compiler/GHC/Cmm/ThreadSanitizer.hs
- + compiler/GHC/Cmm/UniqueRenamer.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/BlockLayout.hs
- compiler/GHC/CmmToAsm/Dwarf.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PPC/Instr.hs
- compiler/GHC/CmmToAsm/RV64/CodeGen.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e1bfbb7a68249d2174c84280215e4cc4e562435f...60db6c2581d1e80d04b2a56576d54677f36db069
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e1bfbb7a68249d2174c84280215e4cc4e562435f...60db6c2581d1e80d04b2a56576d54677f36db069
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/20240920/bf33a54d/attachment-0001.html>
More information about the ghc-commits
mailing list