[Git][ghc/ghc][wip/bump-base] 35 commits: rts: Teach getNumProcessors to return available processors

Ben Gamari gitlab at gitlab.haskell.org
Sun May 31 15:15:28 UTC 2020



Ben Gamari pushed to branch wip/bump-base 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

- - - - -
97b396b3 by Daniel Gröber at 2020-05-31T10:14:52-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.

- - - - -
df70fcfc by Daniel Gröber at 2020-05-31T10:14:52-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().

- - - - -
61a5f17f by Daniel Gröber at 2020-05-31T10:14:52-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.

- - - - -
0f5ab025 by Ben Gamari at 2020-05-31T10:14:53-04:00
testsuite: Add test for #18151

- - - - -
6d2cc1a1 by Ben Gamari at 2020-05-31T10:14:53-04:00
testsuite: Add test for desugaring of PostfixOperators

- - - - -
59e6e58e by Ben Gamari at 2020-05-31T10:14:53-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.

- - - - -
3d72609c by Kirill Elagin at 2020-05-31T10:15:19-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.

- - - - -
ea50b83f by Ben Gamari at 2020-05-31T10:15:19-04:00
nonmoving: Optimise log2_ceil

- - - - -
09e0aa36 by Bodigrim at 2020-05-31T10:15:20-04:00
Clarify description of fromListN
- - - - -
57bad180 by Bodigrim at 2020-05-31T10:15:20-04:00
Apply suggestion to libraries/base/GHC/Exts.hs
- - - - -
1401363d by fendor at 2020-05-31T10:15:24-04:00
Add `isInScope` check to `lintCoercion`

Mirrors the behaviour of `lintType`.

- - - - -
5ab9d2b2 by fendor at 2020-05-31T10:15:24-04:00
Lint rhs of IfaceRule

- - - - -
2af2f60f by Jeremy Schlatter at 2020-05-31T10:15:27-04:00
Fix wording in documentation

The duplicate "orphan instance" phrase here doesn't make sense, and was
probably an accident.

- - - - -
0bcf3237 by Takenobu Tani at 2020-05-31T10:15: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

- - - - -
268d9b56 by Ben Gamari at 2020-05-31T10:15:53-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.

- - - - -
495c1593 by Ben Gamari at 2020-05-31T10:15:53-04:00
testsuite: Refactor ghostscript detection

Tamar reported that he saw crashes due to unhandled exceptions.

- - - - -
06cf3101 by Ben Gamari at 2020-05-31T10:15:53-04:00
testsuite/perf_notes: Fix ill-typed assignments

- - - - -
118de0ff by Ben Gamari at 2020-05-31T10:15:53-04:00
testsuite/testutil: Fix bytes/str mismatch

- - - - -
087704db by Ben Gamari at 2020-05-31T10:15:53-04:00
testsuite: Work around spurious mypy failure

- - - - -
0536fe91 by Takenobu Tani at 2020-05-31T10:15:55-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

- - - - -
999c1f83 by Takenobu Tani at 2020-05-31T10:15:55-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

- - - - -
4b335c4f by Sylvain Henry at 2020-05-31T10:16:16-04:00
Hadrian: fix binary-dist target for cross-compilation

- - - - -
3aeae2c1 by Vladislav Zavialov at 2020-05-31T10:16:16-04:00
Improve parser error messages for the @-operator

Since GHC diverges from the Haskell Report by allowing the user
to define (@) as an infix operator, we better give a good
error message when the user does so unintentionally.

In general, this is rather hard to do, as some failures will be
discovered only in the renamer or the type checker:

	x :: (Integer, Integer)
	x @ (a, b) = (1, 2)

This patch does *not* address this general case.

However, it gives much better error messages when the binding
is not syntactically valid:

	pairs xs @ (_:xs') = zip xs xs'

Before this patch, the error message was rather puzzling:

	<interactive>:1:1: error: Parse error in pattern: pairs

After this patch, the error message includes a hint:

	<interactive>:1:1: error:
	    Parse error in pattern: pairs
	    In a function binding for the ‘@’ operator.
	    Perhaps you meant an as-pattern, which must not be surrounded by whitespace

- - - - -
bb31292c by Vladislav Zavialov at 2020-05-31T10:16:16-04:00
Improve parser error messages for TypeApplications

With this patch, we always parse  f @t  as a type application,
thereby producing better error messages.

This steals two syntactic forms:

* Prefix form of the @-operator in expressions. Since the @-operator is
  a divergence from the Haskell Report anyway, this is not a major loss.

* Prefix form of @-patterns. Since we are stealing loose infix form
  anyway, might as well sacrifice the prefix form for the sake of much
  better error messages.

- - - - -
6c919f0b by Vladislav Zavialov at 2020-05-31T10:16:17-04:00
Improve parser error messages for TemplateHaskellQuotes

While [e| |], [t| |], [d| |], and so on, steal syntax from list
comprehensions, [| |] and [|| ||] do not steal any syntax.

Thus we can improve error messages by always accepting them in the
lexer. Turns out the renamer already performs necessary validation.

- - - - -
5ce86de8 by John Ericson at 2020-05-31T10:39:29-04:00
Clean up boot vs non-boot disambiguating types

We often have (ModuleName, Bool) or (Module, Bool) pairs for "extended"
module names (without or with a unit id) disambiguating boot and normal
modules. We think this is important enough across the compiler that it
deserves a new nominal product type. We do this with synnoyms and a
functor named with a `Gen` prefix, matching other newly created
definitions.

It was also requested that we keep custom `IsBoot` / `NotBoot` sum type.
So we have it too. This means changing many the many bools to use that
instead.

Updates `haddock` submodule.

- - - - -
9ed36e7b by Simon Peyton Jones at 2020-05-31T10:39:40-04:00
Simple subsumption

This patch simplifies GHC to use simple subsumption.
  Ticket #17775

Implements GHC proposal #287
   https://github.com/ghc-proposals/ghc-proposals/blob/master/
   proposals/0287-simplify-subsumption.rst

All the motivation is described there; I will not repeat it here.
The implementation payload:
 * tcSubType and friends become noticably simpler, because it no
   longer uses eta-expansion when checking subsumption.
 * No deeplyInstantiate or deeplySkolemise

That in turn means that some tests fail, by design; they can all
be fixed by eta expansion.  There is a list of such changes below.

Implementing the patch led me into a variety of sticky corners, so
the patch includes several othe changes, some quite significant:

* I made String wired-in, so that
    "foo" :: String   rather than
    "foo" :: [Char]
  This improves error messages, and fixes #15679

* The pattern match checker relies on knowing about in-scope equality
  constraints, andd adds them to the desugarer's environment using
  addTyCsDs.  But the co_fn in a FunBind was missed, and for some reason
  simple-subsumption ends up with dictionaries there. So I added a
  call to addTyCsDs.  This is really part of #18049.

* I moved the ic_telescope field out of Implication and into
  ForAllSkol instead.  This is a nice win; just expresses the code
  much better.

* There was a bug in GHC.Tc.TyCl.Instance.tcDataFamInstHeader.
  We called checkDataKindSig inside tc_kind_sig, /before/
  solveEqualities and zonking.  Obviously wrong, easily fixed.

* solveLocalEqualitiesX: there was a whole mess in here, around
  failing fast enough.  I discovered a bad latent bug where we
  could successfully kind-check a type signature, and use it,
  but have unsolved constraints that could fill in coercion
  holes in that signature --  aargh.

  It's all explained in Note [Failure in local type signatures]
  in GHC.Tc.Solver. Much better now.

* I fixed a serious bug in anonymous type holes. IN
    f :: Int -> (forall a. a -> _) -> Int
  that "_" should be a unification variable at the /outer/
  level; it cannot be instantiated to 'a'.  This was plain
  wrong.  New fields mode_lvl and mode_holes in TcTyMode,
  and auxiliary data type GHC.Tc.Gen.HsType.HoleMode.

  This fixes #16292, but makes no progress towards the more
  ambitious #16082

* I got sucked into an enormous refactoring of the reporting of
  equality errors in GHC.Tc.Errors, especially in
      mkEqErr1
      mkTyVarEqErr
      misMatchMsg
      misMatchMsgOrCND
  In particular, the very tricky mkExpectedActualMsg function
  is gone.

  It took me a full day.  But the result is far easier to understand.
  (Still not easy!)  This led to various minor improvements in error
  output, and an enormous number of test-case error wibbles.

  One particular point: for occurs-check errors I now just say
     Can't match 'a' against '[a]'
  rather than using the intimidating language of "occurs check".

* Pretty-printing AbsBinds

Tests review

* Eta expansions
   T11305: one eta expansion
   T12082: one eta expansion (undefined)
   T13585a: one eta expansion
   T3102:  one eta expansion
   T3692:  two eta expansions (tricky)
   T2239:  two eta expansions
   T16473: one eta
   determ004: two eta expansions (undefined)
   annfail06: two eta (undefined)
   T17923: four eta expansions (a strange program indeed!)
   tcrun035: one eta expansion

* Ambiguity check at higher rank.  Now that we have simple
  subsumption, a type like
     f :: (forall a. Eq a => Int) -> Int
  is no longer ambiguous, because we could write
     g :: (forall a. Eq a => Int) -> Int
     g = f
  and it'd typecheck just fine.  But f's type is a bit
  suspicious, and we might want to consider making the
  ambiguity check do a check on each sub-term.  Meanwhile,
  these tests are accepted, whereas they were previously
  rejected as ambiguous:
     T7220a
     T15438
     T10503
     T9222

* Some more interesting error message wibbles
   T13381: Fine: one error (Int ~ Exp Int)
           rather than two (Int ~ Exp Int, Exp Int ~ Int)
   T9834:  Small change in error (improvement)
   T10619: Improved
   T2414:  Small change, due to order of unification, fine
   T2534:  A very simple case in which a change of unification order
           means we get tow unsolved constraints instead of one
   tc211: bizarre impredicative tests; just accept this for now

Updates Cabal submodule.

Metric Increase:
  T12150
Metric Decrease:
  haddock.Cabal
  haddock.base

- - - - -
a7a36da8 by Ben Gamari at 2020-05-31T11:15:21-04:00
base: Bump to 4.15.0.0

- - - - -


30 changed files:

- aclocal.m4
- compiler/GHC.hs
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/SPARC/Base.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/InstEnv.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/MakeFile.hs
- compiler/GHC/Driver/Types.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/ImpExp.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Monad.hs
- compiler/GHC/HsToCore/PmCheck.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/HsToCore/PmCheck/Types.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3a81e8fb4a5d243ce443410906dda768a1f66e70...a7a36da8c1943a580f8eb7517b220fba5cd5daa3

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3a81e8fb4a5d243ce443410906dda768a1f66e70...a7a36da8c1943a580f8eb7517b220fba5cd5daa3
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/20200531/4808f6fa/attachment-0001.html>


More information about the ghc-commits mailing list