[Git][ghc/ghc][wip/andreask/elem_rule_fix] 11 commits: PmCheck: Adjust recursion depth for inhabitation test

Thu Apr 2 15:06:30 UTC 2020

Andreas Klebinger pushed to branch wip/andreask/elem_rule_fix at Glasgow Haskell Compiler / GHC

Commits:
7b217179 by Sebastian Graf at 2020-04-01T15:03:24-04:00
PmCheck: Adjust recursion depth for inhabitation test

In #17977, we ran into the reduction depth limit of the typechecker.
That was only a symptom of a much broader issue: The recursion depth
of the coverage checker for trying to instantiate strict fields in the
`nonVoid` test was far too high (100, the `defaultMaxTcBound`).

As a result, we were performing quite poorly on `T17977`.
Short of a proper termination analysis to prove emptyness of a type,
we just arbitrarily default to a much lower recursion limit of 3.

Fixes #17977.

- - - - -
3c09f636 by Andreas Klebinger at 2020-04-01T15:03:59-04:00
Make hadrian pass on the no-colour setting to GHC.

Fixes #17983.

- - - - -
b943b25d by Simon Peyton Jones at 2020-04-02T01:45:58-04:00
Re-engineer the binder-swap transformation

The binder-swap transformation is implemented by the occurrence
analyser -- see Note [Binder swap] in OccurAnal. However it had
a very nasty corner in it, for the case where the case scrutinee
was a GlobalId.  This led to trouble and hacks, and ultimately
to #16296.

This patch re-engineers how the occurrence analyser implements
the binder-swap, by actually carrying out a substitution rather
than by adding a let-binding.  It's all described in
Note [The binder-swap substitution].

I did a few other things along the way

* Fix a bug in StgCse, which could allow a loop breaker to be CSE'd
  away.  See Note [Care with loop breakers] in StgCse.  I think it can
  only show up if occurrence analyser sets up bad loop breakers, but
  still.

* Better commenting in SimplUtils.prepareAlts

* A little refactoring in CoreUnfold; nothing significant
  e.g. rename CoreUnfold.mkTopUnfolding to mkFinalUnfolding

* Renamed CoreSyn.isFragileUnfolding to hasCoreUnfolding

* Move mkRuleInfo to CoreFVs

We observed respectively 4.6% and 5.9% allocation decreases for the following
tests:

Metric Decrease:
    T9961
    haddock.base

- - - - -
42d68364 by Sebastian Graf at 2020-04-02T01:46:34-04:00
Preserve precise exceptions in strictness analysis

Fix #13380 and #17676 by

1. Changing `raiseIO#` to have `topDiv` instead of `botDiv`
2. Give it special treatment in `Simplifier.Util.mkArgInfo`, treating it
   as if it still had `botDiv`, to recover dead code elimination.

This is the first commit of the plan outlined in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2525#note_260886.

- - - - -
0a88dd11 by Ömer Sinan Ağacan at 2020-04-02T01:47:25-04:00
Fix a pointer format string in RTS

- - - - -
5beac042 by Ömer Sinan Ağacan at 2020-04-02T01:48:05-04:00
Remove unused closure stg_IND_direct

- - - - -
88f38b03 by Ben Gamari at 2020-04-02T01:48:42-04:00
Session: Memoize stderrSupportsAnsiColors

Not only is this a reasonable efficiency measure but it avoids making
reentrant calls into ncurses, which is not thread-safe. See #17922.

- - - - -
27740f24 by Ryan Scott at 2020-04-02T01:49:21-04:00
Make Hadrian build with Cabal-3.2

GHC 8.10 ships with `Cabal-3.2.0.0`, so it would be convenient to
make Hadrian supporting building against 3.2.* instead of having to
rebuild the entirety of `Cabal-3.0.0.0`. There is one API change in
`Cabal-3.2.*` that affects Hadrian: the `synopsis` and `description`
functions now return `ShortText` instead of `String`. Since Hadrian
manipulates these `String`s in various places, I found that the
simplest fix was to use CPP to convert `ShortText` to `String`s
where appropriate.

- - - - -
49802002 by Sylvain Henry at 2020-04-02T01:50:00-04:00
Update Stack resolver for hadrian/build-stack

Broken by 57b888c0e90be7189285a6b078c30b26d0923809

- - - - -
30a63e79 by Ryan Scott at 2020-04-02T01:50:36-04:00
Fix two ASSERT buglets in reifyDataCon

Two `ASSERT`s in `reifyDataCon` were always using `arg_tys`, but
`arg_tys` is not meaningful for GADT constructors. In fact, it's
worse than non-meaningful, since using `arg_tys` when reifying a
GADT constructor can lead to failed `ASSERT`ions, as #17305
demonstrates.

This patch applies the simplest possible fix to the immediate
problem. The `ASSERT`s now use `r_arg_tys` instead of `arg_tys`, as
the former makes sure to give something meaningful for GADT
constructors. This makes the panic go away at the very least. There
is still an underlying issue with the way the internals of
`reifyDataCon` work, as described in
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227023, but we
leave that as future work, since fixing the underlying issue is
much trickier (see
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227087).

- - - - -
dc1947d8 by Andreas Klebinger at 2020-04-02T17:06:10+02:00
Rework treatment of `elem`. Add UTF8 GHC.CString functions.

We optimize `elem` now in more ways than before.

A fusion RULE for elem was broken preventing it from firing.
Fixing this allows a call to elem on a known list to be translated
into a series of equality checks. These ultimately simply to a
single case expression.

It will also turn into a fold for dynamic lists when list fusion
applies.

This logic however does not work on string literals. For this reason
I added a rule to do the transformation into a case explicitly via a
built in rule. It will fire for any short string literals. (<=32 Bytes).

Longer calls to elem on string literals are rewritten to calls
to elem variants specialized to string literals.

This means we will rewrite:
    * c `elem` (unpackCString "Foo"#) => elemCString# c' "Foo"#
    * c `elem` (unpackCStringUtf8 "Bär"#) => elemCStringUtf8# c' "Bär"#

This means all calls to elem on string literals, as well as many
on other statically known lists should now be allocation free.

As a byproduct GHC.CString functionality is now available for Ascii
and UTF8 strings. The following missing UTF8 variants were
added: unpackAppendCStringUtf8#, unpackFoldrCStringUtf8#

They work just like their ascii counterparts. Which hopefully
makes proper UTF8 support easier for library authors.

A version of `elem` operating on known string literals was added:
* elemCString#     :: Char# -> Addr# -> Bool
* elemCStringUtf8# :: Char# -> Addr# -> Bool

- - - - -

30 changed files:

- compiler/GHC/Core.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Op/ConstantFold.hs
- compiler/GHC/Core/Op/OccurAnal.hs
- compiler/GHC/Core/Op/Simplify.hs
- compiler/GHC/Core/Op/Simplify/Utils.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Stg/CSE.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Id/Info.hs
- compiler/GHC/Types/Id/Make.hs
- compiler/main/SysTools/Terminal.hs
- compiler/prelude/PrelNames.hs
- compiler/prelude/primops.txt.pp
- compiler/typecheck/TcSplice.hs
- compiler/utils/Util.hs
- hadrian/hadrian.cabal
- hadrian/src/Hadrian/Haskell/Cabal/Parse.hs
- hadrian/src/Rules/Library.hs
- hadrian/src/Settings/Builders/Ghc.hs
- hadrian/stack.yaml

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d6c0da2267233daddc6d2f96013ec1394bf588e4...dc1947d809f373aae48e99d0411d2c5de62202b3

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d6c0da2267233daddc6d2f96013ec1394bf588e4...dc1947d809f373aae48e99d0411d2c5de62202b3
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/20200402/8cd536b8/attachment.html>