[Git][ghc/ghc][wip/dmdanal-precise-exn] 48 commits: Don't use non-portable operator "==" in configure.ac

Sebastian Graf gitlab at gitlab.haskell.org
Sat Mar 28 12:48:14 UTC 2020



Sebastian Graf pushed to branch wip/dmdanal-precise-exn at Glasgow Haskell Compiler / GHC


Commits:
e1aa4052 by PHO at 2020-03-17T07:36:09-04:00
Don't use non-portable operator "==" in configure.ac

The test operator "==" is a Bash extension and produces a wrong result
if /bin/sh is not Bash.

- - - - -
89f034dd by Maximilian Tagher at 2020-03-17T07:36:48-04:00
Document the units of -ddump-timings

Right now, in the output of -ddump-timings to a file, you can't tell what the units are:

```
CodeGen [TemplateTestImports]: alloc=22454880 time=14.597
```

I believe bytes/milliseconds are the correct units, but confirmation would be appreciated. I'm basing it off of this snippet from `withTiming'`:

```
when (verbosity dflags >= 2 && prtimings == PrintTimings)
  $ liftIO $ logInfo dflags (defaultUserStyle dflags)
      (text "!!!" <+> what <> colon <+> text "finished in"
       <+> doublePrec 2 time
       <+> text "milliseconds"
       <> comma
       <+> text "allocated"
       <+> doublePrec 3 (realToFrac alloc / 1024 / 1024)
       <+> text "megabytes")
```

which implies time is in milliseconds, and allocations in bytes (which divided by 1024 would be KB, and again would be MB)

- - - - -
beffa147 by Simon Peyton Jones at 2020-03-17T07:37:25-04:00
Implement mapTyCo like foldTyCo

This patch makes mapType use the successful idiom described
in TyCoRep
   Note [Specialising foldType]

I have not yet changed any functions to use mapType, though there
may be some suitable candidates.

This patch should be a no-op in terms of functionality but,
because it inlines the mapper itself, I'm hoping that there may
be some modest perf improvements.

Metric Decrease:
    T5631
    T5642
    T3064
    T9020
    T14683
    hie002
    haddock.Cabal
    haddock.base
    haddock.compiler

- - - - -
5800ebfe by Ömer Sinan Ağacan at 2020-03-17T07:38:08-04:00
Don't update ModDetails with CafInfos when opts are disabled

This is consistent with the interface file behavior where we omit
HsNoCafRefs annotations with -fomit-interface-pragmas (implied by -O0).

ModDetails and ModIface are just different representations of the same
thing, so they really need to be in sync. This patch does the right
thing and does not need too much explanation, but here's an example of a
problem not doing this causes in !2842:

    -- MyInteger.hs
    module MyInteger
      ( MyInteger (MyInteger)
      , ToMyInteger (toMyInteger)
      ) where

    newtype MyInteger = MyInteger Integer

    class ToMyInteger a where
      toMyInteger :: a -> MyInteger

    instance ToMyInteger Integer where
      toMyInteger = MyInteger {- . succ -}

    -- Main.hs
    module Main
      ( main
      ) where

    import MyInteger (MyInteger (MyInteger), toMyInteger)

    main :: IO ()
    main = do
      let (MyInteger i) = (id . toMyInteger) (41 :: Integer)
      print i

If I build this with -O0, without this fix, we generate a ModDetails with
accurate LFInfo for toMyInteger (MyInteger.$fToMyIntegerInteger) which says that
it's a LFReEntrant with arity 1. This means in the use site (Main) we tag the
value:

    R3 = MyInteger.$fToMyIntegerInteger_closure + 1;
    R2 = GHC.Base.id_closure;
    R1 = GHC.Base.._closure;
    Sp = Sp - 16;
    call stg_ap_ppp_fast(R4, R3, R2, R1) args: 24, res: 0, upd: 24;

Now we change the definition by uncommenting the `succ` part and it becomes a thunk:

    MyInteger.$fToMyIntegerInteger [InlPrag=INLINE (sat-args=0)]
      :: MyInteger.ToMyInteger GHC.Integer.Type.Integer
    [GblId[DFunId(nt)]] =
        {} \u [] $ctoMyInteger_rEA;

and its LFInfo is now LFThunk. This change in LFInfo makes a difference in the
use site: we can no longer tag it.

But becuase the interface fingerprint does not change (because ModIface does not
change) we don't rebuild Main and tag the thunk.

(1.2% increase in allocations when building T12545 on armv7 because we
generate more code without CafInfos)

Metric Increase:
    T12545

- - - - -
5b632dad by Paavo at 2020-03-17T07:38:48-04:00
Add example for Data.Semigroup.diff

- - - - -
4d85d68b by Paavo at 2020-03-17T07:38:48-04:00
Clean up

- - - - -
75168d07 by Paavo at 2020-03-17T07:38:48-04:00
Make example collapsible

- - - - -
53ff2cd0 by Richard Eisenberg at 2020-03-17T13:46:57+00:00
Fix #17021 by checking more return kinds

All the details are in new Note [Datatype return kinds] in
TcTyClsDecls.

Test case: typecheck/should_fail/T17021{,b}
           typecheck/should_compile/T17021a

Updates haddock submodule

- - - - -
528df8ec by Sylvain Henry at 2020-03-18T10:06:43-04:00
Modules: Core operations (#13009)

- - - - -
4e8a71c1 by Richard Eisenberg at 2020-03-18T10:07:19-04:00
Add release note about fix to #16502.

We thought we needed to update the manual, but the fix for #16502
actually brings the implementation in line with the manual. So we
just alert users of how to update their code.

- - - - -
5cbf9934 by Andreas Klebinger at 2020-03-19T00:39:27-04:00
Update "GHC differences to the FFI Chapter" in user guide.

The old entry had a heavy focus on how things had been. Which is
not what I generally look for in a user guide.

I also added a small section on behaviour of nested safe ffi calls.

[skip-ci]

- - - - -
b03fd3bc by Sebastian Graf at 2020-03-19T00:40:06-04:00
PmCheck: Use ConLikeSet to model negative info

In #17911, Simon recognised many warnings stemming from over-long list
unions while coverage checking Cabal's `LicenseId` module.

This patch introduces a new `PmAltConSet` type which uses a `UniqDSet`
instead of an association list for `ConLike`s. For `PmLit`s, it will
still use an assocation list, though, because a similar map data
structure would entail a lot of busy work.

Fixes #17911.

- - - - -
64f20756 by Sylvain Henry at 2020-03-19T12:16:49-04:00
Refactoring: use Platform instead of DynFlags when possible

Metric Decrease:
    ManyConstructors
    T12707
    T13035
    T1969

- - - - -
cb1785d9 by Ömer Sinan Ağacan at 2020-03-19T12:16:54-04:00
FastString: fix eager reading of string ptr in hashStr

This read causes NULL dereferencing when len is 0.

Fixes #17909

In the reproducer in #17909 this bug is triggered as follows:

- SimplOpt.dealWithStringLiteral is called with a single-char string
  ("=" in #17909)

- tailFS gets called on the FastString of the single-char string.

- tailFS checks the length of the string, which is 1, and calls
  mkFastStringByteString on the tail of the ByteString, which is an
  empty ByteString as the original ByteString has only one char.

- ByteString's unsafeUseAsCStringLen returns (NULL, 0) for the empty
  ByteString, which is passed to mkFastStringWith.

- mkFastStringWith gets hash of the NULL pointer via hashStr, which
  fails on empty strings because of this bug.

- - - - -
73a7383e by Richard Eisenberg at 2020-03-20T20:42:56-04:00
Simplify treatment of heterogeneous equality

Previously, if we had a [W] (a :: k1) ~ (rhs :: k2), we would
spit out a [D] k1 ~ k2 and part the W as irreducible, hoping for
a unification. But we needn't do this. Instead, we now spit out
a [W] co :: k2 ~ k1 and then use co to cast the rhs of the original
Wanted. This means that we retain the connection between the
spat-out constraint and the original.

The problem with this new approach is that we cannot use the
casted equality for substitution; it's too like wanteds-rewriting-
wanteds. So, we forbid CTyEqCans that mention coercion holes.

All the details are in Note [Equalities with incompatible kinds]
in TcCanonical.

There are a few knock-on effects, documented where they occur.

While debugging an error in this patch, Simon and I ran into
infelicities in how patterns and matches are printed; we made
small improvements.

This patch includes mitigations for #17828, which causes spurious
pattern-match warnings. When #17828 is fixed, these lines should
be removed.

- - - - -
faa36e5b by Sylvain Henry at 2020-03-20T20:43:41-04:00
Hadrian: ignore in-tree GMP objects with ``--lint``

- - - - -
9a96ff6b by Richard Eisenberg at 2020-03-20T20:44:17-04:00
Update core spec to reflect changes to Core.

Key changes:
 * Adds a new rule for forall-coercions over coercion variables, which
was implemented but conspicuously missing from the spec.
 * Adds treatment for FunCo.
 * Adds treatment for ForAllTy over coercion variables.
 * Improves commentary (including restoring a Note lost in
03d4852658e1b7407abb4da84b1b03bfa6f6db3b) in the source.

No changes to running code.

- - - - -
7e0451c6 by Sergej Jaskiewicz at 2020-03-20T20:44:55-04:00
Fix event message in withTiming'

This typo caused generating 'end' events without the corresponding 'begin' events.

- - - - -
1542a626 by Ben Gamari at 2020-03-22T22:37:47-04:00
fs.h: Add missing declarations on Windows

- - - - -
3bcf2ccd by Ben Gamari at 2020-03-22T22:37:47-04:00
Bump process submodule

Avoids redundant case alternative warning.

- - - - -
3b363ef9 by Ben Gamari at 2020-03-22T22:37:47-04:00
testsuite: Normalize slashes in ghc-api annotations output

Enable `normalise_slashes` on `annotations`, `listcomps`, and
`parseTree` to fix Windows failures.

- - - - -
25fc9429 by Ben Gamari at 2020-03-22T22:37:47-04:00
testsuite: Update expected output on Windows

- - - - -
7f58ec6d by Ben Gamari at 2020-03-22T22:37:47-04:00
testsuite: Fix TOP of T17786

- - - - -
aadcd909 by GHC GitLab CI at 2020-03-22T22:37:47-04:00
testsuite: Update expected output on Windows

- - - - -
dc1eb10d by GHC GitLab CI at 2020-03-22T22:37:47-04:00
hadrian: Fix executable extension passed to testsuite driver

- - - - -
58f62e2c by GHC GitLab CI at 2020-03-22T22:37:47-04:00
gitlab-ci: Require that Windows-hadrian job passes

- - - - -
8dd2415d by Ben Gamari at 2020-03-22T22:37:47-04:00
hadrian: Eliminate redundant .exe from GHC path

Previously we were invoking:

    bash -c
    "c:/GitLabRunner/builds/eEQrxK4p/0/ghc/ghc/toolchain/bin/ghc.exe.exe
    testsuite/mk/ghc-config.hs -o _build/test/bin/ghc-config.exe"

- - - - -
373621f6 by Ben Gamari at 2020-03-22T22:37:47-04:00
Bump hsc2hs submodule

- - - - -
abc02b40 by Hécate at 2020-03-22T22:38:33-04:00
Annotate the non-total function in Data.Foldable as such

- - - - -
19f12557 by Josef Svenningsson at 2020-03-23T14:05:33-04:00
Fix ApplicativeDo regression #17835

A previous fix for #15344 made sure that monadic 'fail' is used properly
when translating ApplicativeDo. However, it didn't properly account
for when a 'fail' will be inserted which resulted in some programs
failing with a type error.

- - - - -
2643ba46 by Paavo at 2020-03-24T08:31:32-04:00
Add example and doc for Arg (Fixes #17153)

- - - - -
ac492646 by Sebastian Graf at 2020-03-26T19:01:17+01: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.

- - - - -
466e9229 by Sebastian Graf at 2020-03-27T13:00:22+01:00
Preserve precise exceptions in strictness analysis

The "IO hack" (which is a fallback to preserve precise exceptions
semantics and thus *soundness*, rather than some smart thing that
increases *precision*) always was quite hard to understand. That led to
a misguided effort to simplify it (!1829), because the Note wasn't
particularly clear about what kinds of side-effects it cares about.

The implementation seemed to care about preserving precise exception
semantics, but failed to deliver for the central case of `raiseIO#`
(#17676), which is in stark contrast to one of the motivating examples
in the Note (the one about `exitWith ExitSuccess`).

This patch rewords the Note to apply to IO actions throwing precise
exceptions, rather than all side-effecting IO actions (such as write
effects) in general. Also it makes this clear in the implementation by
extracting the rather opaque `io_hack_reqd` into
`CoreUtils.exprMightThrowPreciseException`.

In fact, that alone wasn't enough to fix #17676. It actually turned out
to be a duplicate of #13380, for which we had a fix in 7b087aeb, making
`catchIO#` have `topDiv` from `botDiv`. But that was reverted on the
grounds of regressing dead code elimination too much. In this patch
we introduce `exnDiv` for `raiseIO#`, the `defaultDmd` of which acts
like `topDiv`s (which was the key point which fixed #13380), but
otherwise acts like `botDiv` in terms of dead code elimination.

Fixes #13380 and #17676.

- - - - -
5ce7b106 by Sebastian Graf at 2020-03-27T13:00:22+01:00
Add ConOrDiv to Divergence and see where it gets us

- - - - -
46399b96 by Sebastian Graf at 2020-03-27T13:00:22+01:00
Actually use conDiv

- - - - -
d976e90f by Sebastian Graf at 2020-03-27T13:00:22+01:00
Attempt to make ensureArgs do the right thing

- - - - -
39a6b95e by Sebastian Graf at 2020-03-27T13:00:22+01:00
More pondering over the can of worms I opened

- - - - -
b0334149 by Sebastian Graf at 2020-03-27T13:00:22+01:00
A bunch of fixes involving the new Divergence lattice

- - - - -
f4330a23 by Sebastian Graf at 2020-03-27T13:00:22+01:00
typo

- - - - -
14566678 by Sebastian Graf at 2020-03-27T13:00:22+01:00
Add strictness signature for a bunch of wired in Ids

- - - - -
95522bb3 by Sebastian Graf at 2020-03-27T13:00:23+01:00
Accept a bunch of testcase changes

- - - - -
e1a34001 by Sebastian Graf at 2020-03-27T13:00:23+01:00
Rename isBot* to isDeadEnd*

- - - - -
f011a336 by Sebastian Graf at 2020-03-27T13:00:23+01:00
Comments

- - - - -
63199442 by Sebastian Graf at 2020-03-27T13:00:23+01:00
Assume that precise exceptions can only be thrown from IO

- - - - -
cb4f0c6b by Sebastian Graf at 2020-03-27T13:00:23+01:00
Accept new testsuite results

- - - - -
e6d02e3e by Sebastian Graf at 2020-03-27T15:21:15+01:00
Polish Notes

- - - - -
5e894f11 by Sebastian Graf at 2020-03-27T15:39:45+01:00
More comments

- - - - -
516987db by Sebastian Graf at 2020-03-28T13:47:58+01:00
Change forcesRealWorld to work like the old IO hack

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/linters/check-cpp.py
- compiler/GHC.hs
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Cmm/DebugBlock.hs
- compiler/GHC/Cmm/Expr.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/Lint.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Opt.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Pipeline.hs
- compiler/GHC/Cmm/Ppr.hs
- compiler/GHC/Cmm/Ppr/Decl.hs
- compiler/GHC/Cmm/Ppr/Expr.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Switch/Implement.hs
- compiler/GHC/Cmm/Type.hs
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/PIC.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen/Amode.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen/Base.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b9975eabd46c9690dacf63b59e5e26fa91b2397a...516987db1eb32bb231063e1e0fa4ff78178b15c9

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b9975eabd46c9690dacf63b59e5e26fa91b2397a...516987db1eb32bb231063e1e0fa4ff78178b15c9
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/20200328/05b07731/attachment-0001.html>


More information about the ghc-commits mailing list