[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 27 commits: rts: Teach getNumProcessors to return available processors
Marge Bot
gitlab at gitlab.haskell.org
Sat May 30 13:36:08 UTC 2020
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
4413828b by Ben Gamari at 2020-05-30T06:07:31-04:00
rts: Teach getNumProcessors to return available processors
Previously we would report the number of physical processors, which
can be quite wrong in a containerized setting. Now we rather return how
many processors are in our affinity mask when possible.
I also refactored the code to prefer platform-specific since this will
report logical CPUs instead of physical (using
`machdep.cpu.thread_count` on Darwin and `cpuset_getaffinity` on FreeBSD).
Fixes #14781.
- - - - -
1449435c by Ben Gamari at 2020-05-30T06:07:31-04:00
users-guide: Note change in getNumProcessors in users guide
- - - - -
3d960169 by Ben Gamari at 2020-05-30T06:07:31-04:00
rts: Drop compatibility shims for Windows Vista
We can now assume that the thread and processor group interfaces are
available.
- - - - -
7f8f948c by Peter Trommler at 2020-05-30T06:08:07-04:00
PPC NCG: Fix .size directive on powerpc64 ELF v1
Thanks to Sergei Trofimovich for pointing out the issue.
Fixes #18237
- - - - -
7c555b05 by Andreas Klebinger at 2020-05-30T06:08:43-04:00
Optimize GHC.Utils.Monad.
Many functions in this module are recursive and as such are marked
loop breakers. Which means they are unlikely to get an unfolding.
This is *bad*. We always want to specialize them to specific Monads.
Which requires a visible unfolding at the use site.
I rewrote the recursive ones from:
foo f x = ... foo x' ...
to
foo f x = go x
where
go x = ...
As well as giving some pragmas to make all of them available
for specialization.
The end result is a reduction of allocations of about -1.4% for
nofib/spectral/simple/Main.hs when compiled with `-O`.
-------------------------
Metric Decrease:
T12425
T14683
T5631
T9233
T9675
T9961
WWRec
-------------------------
- - - - -
8b1cb5df by Ben Gamari at 2020-05-30T06:09:20-04:00
Windows: Bump Windows toolchain to 0.2
- - - - -
6947231a by Zubin Duggal at 2020-05-30T06:10:02-04:00
Simplify contexts in GHC.Iface.Ext.Ast
- - - - -
26142d19 by Daniel Gröber at 2020-05-30T09:35:32-04:00
Cleanup OVERWRITING_CLOSURE logic
The code is just more confusing than it needs to be. We don't need to mix
the threaded check with the ldv profiling check since ldv's init already
checks for this. Hence they can be two separate checks. Taking the sanity
checking into account is also cleaner via DebugFlags.sanity. No need for
checking the DEBUG define.
The ZERO_SLOP_FOR_LDV_PROF and ZERO_SLOP_FOR_SANITY_CHECK definitions the
old code had also make things a lot more opaque IMO so I removed those.
- - - - -
f884f60d by Daniel Gröber at 2020-05-30T09:35:32-04:00
Fix OVERWRITING_CLOSURE assuming closures are not inherently used
The new ASSERT in LDV_recordDead() was being tripped up by MVars when
removeFromMVarBlockedQueue() calls OVERWRITING_CLOSURE() via
OVERWRITE_INFO().
- - - - -
1d158799 by Daniel Gröber at 2020-05-30T09:35:32-04:00
Always zero shrunk mutable array slop when profiling
When shrinking arrays in the profiling way we currently don't always zero
the leftover slop. This means we can't traverse such closures in the heap
profiler. The old Note [zeroing slop] and #8402 have some rationale for why
this is so but I belive the reasoning doesn't apply to mutable
closures. There users already have to ensure multiple threads don't step on
each other's toes so zeroing should be safe.
- - - - -
3c119dde by Ben Gamari at 2020-05-30T09:35:33-04:00
testsuite: Add test for #18151
- - - - -
941b8536 by Ben Gamari at 2020-05-30T09:35:33-04:00
testsuite: Add test for desugaring of PostfixOperators
- - - - -
7c460772 by Ben Gamari at 2020-05-30T09:35:33-04:00
HsToCore: Eta expand left sections
Strangely, the comment next to this code already alluded to the fact
that even simply eta-expanding will sacrifice laziness. It's quite
unclear how we regressed so far.
See #18151.
- - - - -
c61a596d by Kirill Elagin at 2020-05-30T09:35:39-04:00
Winferred-safe-imports: Do not exit with error
Currently, when -Winferred-safe-imports is enabled, even when it is not
turned into an error, the compiler will still exit with exit code 1 if
this warning was emitted.
Make sure it is really treated as a warning.
- - - - -
fb28c9dc by Ben Gamari at 2020-05-30T09:35:39-04:00
nonmoving: Optimise log2_ceil
- - - - -
c6bbde4b by Bodigrim at 2020-05-30T09:35:40-04:00
Clarify description of fromListN
- - - - -
e66d45eb by Bodigrim at 2020-05-30T09:35:40-04:00
Apply suggestion to libraries/base/GHC/Exts.hs
- - - - -
fcb29323 by Jeremy Schlatter at 2020-05-30T09:35:42-04:00
Fix wording in documentation
The duplicate "orphan instance" phrase here doesn't make sense, and was
probably an accident.
- - - - -
e6797ded by Matthew Pickering at 2020-05-30T09:35:43-04:00
Use a newtype `Code` for the return type of typed quotations (Proposal #195)
There are three problems with the current API:
1. It is hard to properly write instances for ``Quote m => m (TExp a)`` as the type is the composition
of two type constructors. Doing so in your program involves making your own newtype and
doing a lot of wrapping/unwrapping.
For example, if I want to create a language which I can either run immediately or
generate code from I could write the following with the new API. ::
class Lang r where
_int :: Int -> r Int
_if :: r Bool -> r a -> r a -> r a
instance Lang Identity where
_int = Identity
_if (Identity b) (Identity t) (Identity f) = Identity (if b then t else f)
instance Quote m => Lang (Code m) where
_int = liftTyped
_if cb ct cf = [|| if $$cb then $$ct else $$cf ||]
2. When doing code generation it is common to want to store code fragments in
a map. When doing typed code generation, these code fragments contain a
type index so it is desirable to store them in one of the parameterised
map data types such as ``DMap`` from ``dependent-map`` or ``MapF`` from
``parameterized-utils``.
::
compiler :: Env -> AST a -> Code Q a
data AST a where ...
data Ident a = ...
type Env = MapF Ident (Code Q)
newtype Code m a = Code (m (TExp a))
In this example, the ``MapF`` maps an ``Ident String`` directly to a ``Code Q String``.
Using one of these map types currently requires creating your own newtype and constantly
wrapping every quotation and unwrapping it when using a splice. Achievable, but
it creates even more syntactic noise than normal metaprogramming.
3. ``m (TExp a)`` is ugly to read and write, understanding ``Code m a`` is
easier. This is a weak reason but one everyone
can surely agree with.
- - - - -
60bfcc9f by Takenobu Tani at 2020-05-30T09:35:53-04:00
configure: Modify aclocal.m4 according to new module hierarchy
This patch updates file paths according to new module hierarchy [1]:
* Rename:
* compiler/GHC/Parser.hs <= compiler/parser/Parser.hs
* compiler/GHC/Parser/Lexer.hs <= compiler/Parser/Lexer.hs
* Add:
* compiler/GHC/Cmm/Lexer.hs
[1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
- - - - -
a3711abf by Ben Gamari at 2020-05-30T09:35:54-04:00
testsuite: Don't fail if we can't unlink __symlink_test
Afterall, it's possible we were unable to create it due to lack of
symlink permission.
- - - - -
8641898f by Ben Gamari at 2020-05-30T09:35:54-04:00
testsuite: Refactor ghostscript detection
Tamar reported that he saw crashes due to unhandled exceptions.
- - - - -
8c31a6bf by Ben Gamari at 2020-05-30T09:35:54-04:00
testsuite/perf_notes: Fix ill-typed assignments
- - - - -
f4bc785d by Ben Gamari at 2020-05-30T09:35:54-04:00
testsuite/testutil: Fix bytes/str mismatch
- - - - -
fe75764a by Ben Gamari at 2020-05-30T09:35:54-04:00
testsuite: Work around spurious mypy failure
- - - - -
8bfdc1f8 by Takenobu Tani at 2020-05-30T09:35:56-04:00
Clean up file paths for new module hierarchy
This updates comments only.
This patch replaces file references according to new module hierarchy.
See also:
* https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
* https://gitlab.haskell.org/ghc/ghc/issues/13009
- - - - -
ae9f06ba by Takenobu Tani at 2020-05-30T09:35:56-04:00
Modify file paths to module paths for new module hierarchy
This updates comments only.
This patch replaces module references according to new module
hierarchy [1][2].
For files under the `compiler/` directory, I replace them as
module paths instead of file paths. For instance,
`GHC.Unit.State` instead of `compiler/GHC/Unit/State.hs` [3].
For current and future haddock's markup, this patch encloses
the module name with "" [4].
[1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
[2]: https://gitlab.haskell.org/ghc/ghc/issues/13009
[3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3375#note_276613
[4]: https://haskell-haddock.readthedocs.io/en/latest/markup.html#linking-to-modules
- - - - -
30 changed files:
- aclocal.m4
- compiler/GHC.hs
- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/SPARC/Base.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/InstEnv.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/HsToCore/PmCheck/Types.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/StgToCmm/Expr.hs
- compiler/GHC/StgToCmm/Utils.hs
- compiler/GHC/SysTools/ExtraObj.hs
- compiler/GHC/Tc/Deriv.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/ThToHs.hs
- compiler/GHC/Utils/Monad.hs
- compiler/GHC/Utils/Outputable.hs
- compiler/GHC/Utils/Ppr.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4448ba12bf76cc0dd7c3cee66916bbc428f968c5...ae9f06bac738415f38080b759690229ea802e328
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4448ba12bf76cc0dd7c3cee66916bbc428f968c5...ae9f06bac738415f38080b759690229ea802e328
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/20200530/9f3437d9/attachment-0001.html>
More information about the ghc-commits
mailing list