[Git][ghc/ghc][wip/T18323] 12 commits: Drop 32-bit Windows support

Simon Peyton Jones gitlab at gitlab.haskell.org
Wed Jul 29 09:47:15 UTC 2020



Simon Peyton Jones pushed to branch wip/T18323 at Glasgow Haskell Compiler / GHC


Commits:
aa054d32 by Ben Gamari at 2020-07-27T20:09:07-04:00
Drop 32-bit Windows support

As noted in #18487, we have reached the end of this road.

- - - - -
6da73bbf by Michalis Pardalos at 2020-07-27T20:09:44-04:00
Add minimal test for #12492

- - - - -
47680cb7 by Michalis Pardalos at 2020-07-27T20:09:44-04:00
Use allocate, not ALLOC_PRIM_P for unpackClosure#

ALLOC_PRIM_P fails for large closures, by directly using allocate
we can handle closures which are larger than the block size.

Fixes #12492

- - - - -
3d345c96 by Simon Peyton Jones at 2020-07-27T20:10:19-04:00
Eta-expand the Simplifier monad

This patch eta-expands the Simplifier's monad, using the method
explained in GHC.Core.Unify Note [The one-shot state monad trick].
It's part of the exta-expansion programme in #18202.

It's a tiny patch, but is worth a 1-2% reduction in bytes-allocated
by the compiler.  Here's the list, based on the compiler-performance
tests in perf/compiler:

                    Reduction in bytes allocated
   T10858(normal)      -0.7%
   T12425(optasm)      -1.3%
   T13056(optasm)      -1.8%
   T14683(normal)      -1.1%
   T15164(normal)      -1.3%
   T15630(normal)      -1.4%
   T17516(normal)      -2.3%
   T18282(normal)      -1.6%
   T18304(normal)      -0.8%
   T1969(normal)       -0.6%
   T4801(normal)       -0.8%
   T5321FD(normal)     -0.7%
   T5321Fun(normal)    -0.5%
   T5642(normal)       -0.9%
   T6048(optasm)       -1.1%
   T9020(optasm)       -2.7%
   T9233(normal)       -0.7%
   T9675(optasm)       -0.5%
   T9961(normal)       -2.9%
   WWRec(normal)       -1.2%

Metric Decrease:
    T12425
    T9020
    T9961

- - - - -
57aca6bb by Ben Gamari at 2020-07-27T20:10:54-04:00
gitlab-ci: Ensure that Hadrian jobs don't download artifacts

Previously the Hadrian jobs had the default dependencies, meaning that
they would download artifacts from all jobs of earlier stages. This is
unneccessary.

- - - - -
0a815cea by Ben Gamari at 2020-07-27T20:10:54-04:00
gitlab-ci: Bump bootstrap compiler to 8.8.4

Hopefully this will make the Windows jobs a bit more reliable.

- - - - -
0bd60059 by Simon Peyton Jones at 2020-07-28T02:01:49-04:00
This patch addresses the exponential blow-up in the simplifier.

Specifically:
  #13253 exponential inlining
  #10421 ditto
  #18140 strict constructors
  #18282 another nested-function call case

This patch makes one really significant changes: change the way that
mkDupableCont handles StrictArg.  The details are explained in
GHC.Core.Opt.Simplify Note [Duplicating StrictArg].

Specific changes

* In mkDupableCont, when making auxiliary bindings for the other arguments
  of a call, add extra plumbing so that we don't forget the demand on them.
  Otherwise we haev to wait for another round of strictness analysis. But
  actually all the info is to hand.  This change affects:
  - Make the strictness list in ArgInfo be [Demand] instead of [Bool],
    and rename it to ai_dmds.
  - Add as_dmd to ValArg
  - Simplify.makeTrivial takes a Demand
  - mkDupableContWithDmds takes a [Demand]

There are a number of other small changes

1. For Ids that are used at most once in each branch of a case, make
   the occurrence analyser record the total number of syntactic
   occurrences.  Previously we recorded just OneBranch or
   MultipleBranches.

   I thought this was going to be useful, but I ended up barely
   using it; see Note [Note [Suppress exponential blowup] in
   GHC.Core.Opt.Simplify.Utils

   Actual changes:
     * See the occ_n_br field of OneOcc.
     * postInlineUnconditionally

2. I found a small perf buglet in SetLevels; see the new
   function GHC.Core.Opt.SetLevels.hasFreeJoin

3. Remove the sc_cci field of StrictArg.  I found I could get
   its information from the sc_fun field instead.  Less to get
   wrong!

4. In ArgInfo, arrange that ai_dmds and ai_discs have a simpler
   invariant: they line up with the value arguments beyond ai_args
   This allowed a bit of nice refactoring; see isStrictArgInfo,
   lazyArgcontext, strictArgContext

There is virtually no difference in nofib. (The runtime numbers
are bogus -- I tried a few manually.)

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
            fft          +0.0%     -2.0%    -48.3%    -49.4%      0.0%
     multiplier          +0.0%     -2.2%    -50.3%    -50.9%      0.0%
--------------------------------------------------------------------------------
            Min          -0.4%     -2.2%    -59.2%    -60.4%      0.0%
            Max          +0.0%     +0.1%     +3.3%     +4.9%      0.0%
 Geometric Mean          +0.0%     -0.0%    -33.2%    -34.3%     -0.0%

Test T18282 is an existing example of these deeply-nested strict calls.
We get a big decrease in compile time (-85%) because so much less
inlining takes place.

Metric Decrease:
    T18282

- - - - -
6ee07b49 by Sylvain Henry at 2020-07-28T02:02:27-04:00
Bignum: add support for negative shifts (fix #18499)

shiftR/shiftL support negative arguments despite Haskell 2010 report
saying otherwise. We explicitly test for negative values which is bad
(it gets in the way of constant folding, etc.). Anyway, for consistency
we fix Bits instancesof Integer/Natural.

- - - - -
f305bbfd by Peter Trommler at 2020-07-28T02:03:02-04:00
config: Fix Haskell platform constructor w/ params

Fixes #18505

- - - - -
318bb17c by Oleg Grenrus at 2020-07-28T20:54:13-04:00
Fix typo in haddock

Spotted by `vilpan` on `#haskell`

- - - - -
39c89862 by Sergei Trofimovich at 2020-07-28T20:54:50-04:00
ghc/mk: don't build gmp packages for BIGNUM_BACKEND=native

Before this change make-based `BIGNUM_BACKEND=native` build was failing as:

```
x86_64-pc-linux-gnu-gcc: error: libraries/ghc-bignum/gmp/objs/*.o: No such file or directory
```

This happens because ghc.mk was pulling in gmp-dependent
ghc-bignum library unconditionally. The change avoid building
ghc-bignum.

Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/18437
Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>

- - - - -
3f406c0f by Simon Peyton Jones at 2020-07-29T10:46:50+01:00
Add right-to-left rule for pattern bindings

Fix #18323 by adding a few lines of code to handle non-recursive
pattern bindings.  see GHC.Tc.Gen.Bind
Note [Special case for non-recursive pattern bindings]

Alas, this confused the pattern-match overlap checker; see #18323.

Note that this patch only affects pattern bindings like that
for (x,y) in this program

  combine :: (forall a . [a] -> a) -> [forall a. a -> a]
          -> ((forall a . [a] -> a), [forall a. a -> a])

  breaks = let (x,y) = combine head ids
           in x y True

We need ImpredicativeTypes for those [forall a. a->a] types to be
valid. And with ImpredicativeTypes the old, unprincipled "allow
unification variables to unify with a polytype" story actually
works quite well. So this test compiles fine (if delicatedly) with
old GHCs; but not with QuickLook unless we add this patch

- - - - -


30 changed files:

- .gitlab-ci.yml
- aclocal.m4
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Monad.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Gen/Match.hs-boot
- compiler/GHC/Tc/Utils/Zonk.hs
- compiler/GHC/Types/Basic.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Id/Info.hs
- docs/users_guide/8.12.1-notes.rst
- ghc.mk
- libraries/base/Data/Bits.hs
- libraries/base/GHC/IO.hs
- rts/PrimOps.cmm
- testsuite/tests/numeric/should_compile/T14465.stdout
- testsuite/tests/numeric/should_compile/T7116.stdout
- + testsuite/tests/numeric/should_run/T18499.hs
- + testsuite/tests/numeric/should_run/T18499.stdout
- testsuite/tests/numeric/should_run/all.T
- + testsuite/tests/perf/compiler/T10421.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/888a920ac84dc57c327abe468b336bea3065c801...3f406c0fabfc84a3044451f6fcbae4ba0d04f647

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/888a920ac84dc57c327abe468b336bea3065c801...3f406c0fabfc84a3044451f6fcbae4ba0d04f647
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/20200729/4bd95d58/attachment.html>


More information about the ghc-commits mailing list