[Git][ghc/ghc][wip/dmdanal-precise-exn] 18 commits: Change zipWith to zipWithEqual in a few places

Sebastian Graf gitlab at gitlab.haskell.org
Wed Apr 15 09:17:06 UTC 2020 


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


Commits:
0da186c1 by Krzysztof Gogolewski at 2020-04-14T07:55:20-04:00
Change zipWith to zipWithEqual in a few places

- - - - -
074c1ccd by Andreas Klebinger at 2020-04-14T07:55:55-04:00
Small change to the windows ticker.

We already have a function to go from time to ms so use it.
Also expand on the state of timer resolution.

- - - - -
b69cc884 by Alp Mestanogullari at 2020-04-14T07:56:38-04:00
hadrian: get rid of unnecessary levels of nesting in source-dist

- - - - -
d0c3b069 by Julien Debon at 2020-04-14T07:57:16-04:00
doc (Foldable): Add examples to Data.Foldable

See #17929

- - - - -
5b08e0c0 by Ben Gamari at 2020-04-14T23:28:20-04:00
StgCRun: Enable unwinding only on Linux

It's broken on macOS due and SmartOS due to assembler differences
(#15207) so let's be conservative in enabling it. Also, refactor things
to make the intent clearer.

- - - - -
27cc2e7b by Ben Gamari at 2020-04-14T23:28:57-04:00
rts: Don't mark evacuate_large as inline

This function has two callsites and is quite large. GCC consequently
decides not to inline and warns instead. Given the situation, I can't
blame it. Let's just remove the inline specifier.

- - - - -
9853fc5e by Ben Gamari at 2020-04-14T23:29:48-04:00
base: Enable large file support for OFD locking impl.

Not only is this a good idea in general but this should also avoid
issue #17950 by ensuring that off_t is 64-bits.

- - - - -
7b41f21b by Matthew Pickering at 2020-04-14T23:30:24-04:00
Hadrian: Make -i paths absolute

The primary reason for this change is that ghcide does not work with
relative paths. It also matches what cabal and stack do, they always
pass absolute paths.

- - - - -
41230e26 by Daniel Gröber at 2020-04-14T23:31:01-04:00
Zero out pinned block alignment slop when profiling

The heap profiler currently cannot traverse pinned blocks because of
alignment slop. This used to just be a minor annoyance as the whole block
is accounted into a special cost center rather than the respective object's
CCS, cf. #7275. However for the new root profiler we would like to be able
to visit _every_ closure on the heap. We need to do this so we can get rid
of the current 'flip' bit hack in the heap traversal code.

Since info pointers are always non-zero we can in principle skip all the
slop in the profiler if we can rely on it being zeroed. This assumption
caused problems in the past though, commit a586b33f8e ("rts: Correct
handling of LARGE ARR_WORDS in LDV profiler"), part of !1118, tried to use
the same trick for BF_LARGE objects but neglected to take into account that
shrink*Array# functions don't ensure that slop is zeroed when not
compiling with profiling.

Later, commit 0c114c6599 ("Handle large ARR_WORDS in heap census (fix
as we will only be assuming slop is zeroed when profiling is on.

This commit also reduces the ammount of slop we introduce in the first
place by calculating the needed alignment before doing the allocation for
small objects where we know the next available address. For large objects
we don't know how much alignment we'll have to do yet since those details
are hidden behind the allocateMightFail function so there we continue to
allocate the maximum additional words we'll need to do the alignment.

So we don't have to duplicate all this logic in the cmm code we pull it
into the RTS allocatePinned function instead.

Metric Decrease:
    T7257
    haddock.Cabal
    haddock.base

- - - - -
15fa9bd6 by Daniel Gröber at 2020-04-14T23:31:01-04:00
rts: Expand and add more notes regarding slop

- - - - -
caf3f444 by Daniel Gröber at 2020-04-14T23:31:01-04:00
rts: allocatePinned: Fix confusion about word/byte units

- - - - -
c3c0f662 by Daniel Gröber at 2020-04-14T23:31:01-04:00
rts: Underline some Notes as is conventional

- - - - -
e149dea9 by Daniel Gröber at 2020-04-14T23:31:38-04:00
rts: Fix nomenclature in OVERWRITING_CLOSURE macros

The additional commentary introduced by commit 8916e64e5437 ("Implement
shrinkSmallMutableArray# and resizeSmallMutableArray#.") unfortunately got
this wrong. We set 'prim' to true in overwritingClosureOfs because we
_don't_ want to call LDV_recordDead().

The reason is because of this "inherently used" distinction made in the LDV
profiler so I rename the variable to be more appropriate.

- - - - -
1dd3d18c by Daniel Gröber at 2020-04-14T23:31:38-04:00
Remove call to LDV_RECORD_CREATE for array resizing

- - - - -
19de2fb0 by Daniel Gröber at 2020-04-14T23:31:38-04:00
rts: Assert LDV_recordDead is not called for inherently used closures

The comments make it clear LDV_recordDead should not be called for
inhererently used closures, so add an assertion to codify this fact.

- - - - -
0b934e30 by Ryan Scott at 2020-04-14T23:32:14-04:00
Bump template-haskell version to 2.17.0.0

This requires bumping the `exceptions` and `text` submodules to bring
in commits that bump their respective upper version bounds on
`template-haskell`.

Fixes #17645. Fixes #17696.

Note that the new `text` commit includes a fair number of additions
to the Haddocks in that library. As a result, Haddock has to do more
work during the `haddock.Cabal` test case, increasing the number of
allocations it requires. Therefore,

-------------------------
Metric Increase:
    haddock.Cabal
-------------------------

- - - - -
8b1c64a0 by Sebastian Graf at 2020-04-15T10:44:28+02:00
DmdAnal: Reflect precise exceptions in demand types

This is part two of the "fixing precise exception" plan in
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions
and, in combination with !2956, supercedes !2525.

In #13380 and #17676 we saw that we didn't preserve precise exception
semantics in demand analysis. We fixed that with minimal changes in
!2956, but that is terribly unprincipled.

That unprincipledness results in a loss of precision, which is tracked
by these new test cases:

- `T13380b`: Regression in dead code elimination, because !2956 was too
             syntactic about `raiseIO#`
- `T13380c`: No need to apply the "IO hack" when the IO action may not
             throw a precise exception
- `T13380d`: Demonstrating unsoundness of the "IO hack" when resorting
             to manual state token threading and direct use of primops.
             More details below.

The "IO hack" (which is a fallback to preserve precise exceptions
semantics and thus soundness, rather than some smart thing that
increases precision) is quite a misnomer and is called
`mayThrowPreciseException` now.

Also there is a slight chance that the IO hack was unsound before,
because it assumes that precise exceptions can only be thrown from a
case scrutinee of type `(# State# RealWorld, _ #)`.
I couldn't come up with a program using the `IO` abstraction that
violates this assumption. But it's easy to do so via manual state token
threading and direct use of primops, see `T13380d`. Also similar code
might be generated by Nested CPR in the (hopefully not too) distant
future.

Hence, we now have a more careful test in `forcesRealWorld` that passes
`T13380d`.

As for *how* we fixed these wrinkles: We augmented the `Divergence`
lattice to a diamond with two new elements forming the middle layer:

- `ExnOrDiv`: Means either `Diverges` (, throws an imprecise exception)
              or throws a *precise* exception.
- `ConOrDiv`: Means either `Diverges` (, throws an imprecise exception)
              or converges.

See the wiki page for more implementational details:
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions#replacing-hacks-by-principled-program-analyses

- - - - -
b821abb9 by Sebastian Graf at 2020-04-15T11:16:54+02:00
Fix the perf regression in T12227/T12545

But now T9233 fails because we are doing more work. Temporarily marking
as accepted increase.

Metric Increase:
    T9233

Metric Decrease:
    hie002

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/Core/Arity.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Op/CallArity.hs
- compiler/GHC/Core/Op/DmdAnal.hs
- compiler/GHC/Core/Op/FloatIn.hs
- compiler/GHC/Core/Op/FloatOut.hs
- compiler/GHC/Core/Op/LiberateCase.hs
- compiler/GHC/Core/Op/OccurAnal.hs
- compiler/GHC/Core/Op/SetLevels.hs
- compiler/GHC/Core/Op/Simplify.hs
- compiler/GHC/Core/Op/Simplify/Utils.hs
- compiler/GHC/Core/Op/SpecConstr.hs
- compiler/GHC/Core/Op/WorkWrap/Lib.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Utils/Zonk.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Id.hs
- compiler/GHC/Types/Id/Info.hs
- compiler/GHC/Types/Id/Make.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4d8912eb61de6e2d5de0b6a0b656526e1662705...b821abb9cc2a0a8bc11323bbf830fd95e1aace85

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4d8912eb61de6e2d5de0b6a0b656526e1662705...b821abb9cc2a0a8bc11323bbf830fd95e1aace85
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/20200415/9e62988e/attachment.html>

More information about the ghc-commits mailing list