[Git][ghc/ghc][wip/dmd-arity] 34 commits: Add support for bitreverse primop
Sebastian Graf
gitlab at gitlab.haskell.org
Fri Apr 5 12:23:11 UTC 2019
Sebastian Graf pushed to branch wip/dmd-arity at Glasgow Haskell Compiler / GHC
Commits:
33173a51 by Alexandre at 2019-04-01T07:32:28Z
Add support for bitreverse primop
This commit includes the necessary changes in code and
documentation to support a primop that reverses a word's
bits. It also includes a test.
- - - - -
a3971b4e by Alexandre at 2019-04-01T07:32:28Z
Bump ghc-prim's version where needed
- - - - -
061276ea by Michael Sloan at 2019-04-01T07:32:30Z
Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)
Also removes a couple unnecessary MagicHash pragmas
- - - - -
e468c613 by David Eichmann at 2019-04-01T07:32:34Z
Support Shake's --lint-fsatrace feature.
Using this feature requires fsatrace (e.g. https://github.com/jacereda/fsatrace).
Simply use the `--lint-fsatrace` option when running hadrian.
Shake version >= 0.17.7 is required to support linting out of tree build dirs.
- - - - -
1e9e4197 by Ben Gamari at 2019-04-01T07:32:34Z
gitlab: Add merge request template for backports for 8.8
- - - - -
55650d14 by Ben Gamari at 2019-04-01T07:32:34Z
gitlab: Add some simply issue templates
- - - - -
27b99ed8 by Takenobu Tani at 2019-04-01T07:32:36Z
Clean up URLs to point to GitLab
This moves URL references to old Trac to their corresponding
GitLab counterparts.
This patch does not update the submodule library, such as
libraries/Cabal.
See also !539, !606, !618
[ci skip]
- - - - -
18d1555d by Adam Sandberg Eriksson at 2019-04-01T07:32:38Z
configure: document the use of the LD variable
- - - - -
10352efa by Ben Gamari at 2019-04-01T22:22:34Z
gitlab: Add feature request MR template
- - - - -
1e52054b by Ben Gamari at 2019-04-01T23:16:21Z
gitlab: Move feature request template to issue_templates
Whoops.
- - - - -
e5c21ca9 by Ben Gamari at 2019-04-01T23:16:25Z
gitlab: Mention ~"user facing" label
- - - - -
39282422 by Ryan Scott at 2019-04-02T00:01:38Z
Bump array submodule
This bumps `array` to version 0.5.4.0 so that we can distinguish
it with `MIN_VERSION_array` (as it introduces some changes to the
`Show` instance for `UArray`).
- - - - -
7cf5ba3d by Michal Terepeta at 2019-04-02T00:07:49Z
Improve performance of newSmallArray#
This:
- Hoists part of the condition outside of the initialization loop in
`stg_newSmallArrayzh`.
- Annotates one of the unlikely branches as unlikely, also in
`stg_newSmallArrayzh`.
- Adds a couple of annotations to `allocateMightFail` indicating which
branches are likely to be taken.
Together this gives about 5% improvement.
Signed-off-by: Michal Terepeta <michal.terepeta at gmail.com>
- - - - -
dd9c82ef by David Eichmann at 2019-04-02T00:13:55Z
Hadrian: correct deps for ghc builder.
Previously, when needing ghc as a builder, the ghcDeps (Files
the GHC binary depends on) for the current stage were needed.
This is incorrect as the previous stage's ghc is used for building.
This commit fixes the issue, needing the previous stage's ghcDeps.
- - - - -
345306d3 by Alexandre Baldé at 2019-04-02T16:34:30Z
Fix formatting issue in ghc-prim's changelog [skip ci]
- - - - -
f54b5124 by David Eichmann at 2019-04-02T16:40:39Z
Hadrian: traceAllow deep dependencies when compilling haskell object files.
- - - - -
d132b30a by David Eichmann at 2019-04-02T16:40:39Z
Hadrian: lint ignore autom4te and ghc-pkg cache files.
- - - - -
bf734195 by Simon Marlow at 2019-04-02T16:46:46Z
Add myself to libraries/ghci
- - - - -
5a75ccd0 by klebinger.andreas at gmx.at at 2019-04-03T04:34:57Z
Fix faulty substitutions in StgCse (#11532).
`substBndr` should rename bindings which shadow existing ids.
However while it was renaming the bindings it was not adding proper substitutions
for renamed bindings.
Instead of adding a substitution of the form `old -> new` for renamed
bindings it mistakenly added `old -> old` if no replacement had taken
place while adding none if `old` had been renamed.
As a byproduct this should improve performance, as we no longer add
useless substitutions for unshadowed bindings.
- - - - -
2ec749b5 by Nathan Collins at 2019-04-03T04:41:05Z
users-guide: Fix typo
- - - - -
ea192a09 by Andrew Martin at 2019-04-03T04:41:05Z
base: Add documentation that liftA2 used to not be a typeclass method
- - - - -
733f1b52 by Frank Steffahn at 2019-04-03T04:41:05Z
users-guide: Typo in Users Guide, Glasgow Exts
- - - - -
3364def0 by Ben Gamari at 2019-04-03T04:41:05Z
integer-gmp: Write friendlier documentation for Integer
- - - - -
dd3a3d08 by Ben Gamari at 2019-04-03T04:41:05Z
integer-simple: Add documentation for Integer type
- - - - -
722fdddf by Chris Martin at 2019-04-03T04:41:05Z
Correct two misspellings of "separately"
- - - - -
bf6dbe3d by Chris Martin at 2019-04-03T04:41:05Z
Inline the definition of 'ap' in the Monad laws
The law as it is currently written is meaningless, because nowhere have
we defined the implementation of 'ap'. The reader of the Control.Monad
documentation is provided with only a type signature,
> ap :: Monad m => m (a -> b) -> m a -> m b
an informal description,
> In many situations, the liftM operations can be replaced by uses of
> ap, which promotes function application.
and a relationship between 'ap' and the 'liftM' functions
> return f `ap` x1 `ap` ... `ap` xn
> is equivalent to
> liftMn f x1 x2 ... xn
Without knowing how 'ap' is defined, a law involving 'ap' cannot
provide any guidance for how to write a lawful Monad instance, nor can
we conclude anything from the law.
I suspect that a reader equipped with the understanding that 'ap' was
defined prior to the invention of the Applicative class could deduce
that 'ap' must be defined in terms of (>>=), but nowhere as far as I can
tell have we written this down explicitly for readers without the
benefit of historical context.
If the law is meant to express a relationship among (<*>), (>>=), and
'return', it seems that it is better off making this statement directly,
sidestepping 'ap' altogether.
- - - - -
7b090b53 by Ben Gamari at 2019-04-03T07:57:40Z
configure: Always use AC_LINK_ELSEIF when testing against assembler
This fixes #16440, where the build system incorrectly concluded that the
`.subsections_via_symbols` assembler directive was supported on a Linux
system. This was caused by the fact that gcc was invoked with `-flto`;
when so-configured gcc does not call the assembler but rather simply
serialises its AST for compilation during the final link.
This is described in Note [autoconf assembler checks and -flto].
- - - - -
4626cf21 by Sebastian Graf at 2019-04-03T08:03:47Z
Fix Uncovered set of literal patterns
Issues #16289 and #15713 are proof that the pattern match checker did
an unsound job of estimating the value set abstraction corresponding to
the uncovered set.
The reason is that the fix from #11303 introducing `NLit` was
incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`,
which would have done the necessary case splitting analogous to the
`ConVar` case.
This patch rectifies that by introducing the fresh unification variable
in `LitCon` in value abstraction position rather than pattern postition,
recording a constraint equating it to the constructor expression rather
than the literal. Fixes #16289 and #15713.
- - - - -
6f13e7b1 by Ben Gamari at 2019-04-03T12:12:26Z
gitlab-ci: Build hyperlinked sources for releases
Fixes #16445.
- - - - -
895394c2 by Ben Gamari at 2019-04-03T12:15:06Z
gitlab: Fix label names in issue templates
- - - - -
75abaaea by Yuriy Syrovetskiy at 2019-04-04T08:23:19Z
Replace git.haskell.org with gitlab.haskell.org (#16196)
- - - - -
25c02ea1 by Ryan Scott at 2019-04-04T08:29:29Z
Fix #16518 with some more kind-splitting smarts
This patch corrects two simple oversights that led to #16518:
1. `HsUtils.typeToLHsType` was taking visibility into account in the
`TyConApp` case, but not the `AppTy` case. I've factored out the
visibility-related logic into its own `go_app` function and now
invoke `go_app` from both the `TyConApp` and `AppTy` cases.
2. `Type.fun_kind_arg_flags` did not properly split kinds with
nested `forall`s, such as
`(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply
because `fun_kind_arg_flags`'s `FunTy` case always bailed out and
assumed all subsequent arguments were `Required`, which clearly
isn't the case for nested `forall`s. I tweaked the `FunTy` case
to recur on the result kind.
- - - - -
51fd3571 by Ryan Scott at 2019-04-04T08:35:39Z
Use funPrec, not topPrec, to parenthesize GADT argument types
A simple oversight. Fixes #16527.
- - - - -
e1cc1254 by Sebastian Graf at 2019-04-05T12:23:02Z
Compute demand signatures assuming idArity
This does four things:
1. Look at `idArity` instead of manifest lambdas to decide whether to use LetUp
2. Compute the strictness signature in LetDown assuming at least `idArity`
incoming arguments
3. Remove the special case for trivial RHSs, which is subsumed by 2
4. Don't perform the W/W split when doing so would eta expand a binding.
Otherwise we would eta expand PAPs, causing unnecessary churn in the
Simplifier.
NoFib Results
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
fannkuch-redux +0.3% 0.0%
gg -0.0% -0.1%
maillist +0.2% +0.2%
minimax 0.0% +0.8%
pretty 0.0% -0.1%
scc 0.0% -0.1%
--------------------------------------------------------------------------------
Min -0.0% -0.1%
Max +0.3% +0.8%
Geometric Mean +0.0% +0.0%
- - - - -
30 changed files:
- .gitlab-ci.yml
- + .gitlab/issue_templates/bug.md
- + .gitlab/issue_templates/feature_request.md
- + .gitlab/merge_request_templates/backport-for-8.8.md
- .gitlab/merge_request_templates/merge-request.md
- ANNOUNCE
- CODEOWNERS
- HACKING.md
- README.md
- aclocal.m4
- boot
- compiler/basicTypes/Demand.hs
- compiler/basicTypes/Id.hs
- compiler/basicTypes/IdInfo.hs
- compiler/basicTypes/Var.hs
- compiler/cmm/CmmMachOp.hs
- compiler/cmm/PprC.hs
- compiler/codeGen/StgCmmMonad.hs
- compiler/codeGen/StgCmmPrim.hs
- compiler/coreSyn/CoreArity.hs
- compiler/coreSyn/CoreLint.hs
- compiler/coreSyn/CoreUnfold.hs
- compiler/deSugar/Check.hs
- compiler/deSugar/TmOracle.hs
- compiler/ghci/ByteCodeLink.hs
- compiler/ghci/RtClosureInspect.hs
- compiler/hsSyn/HsUtils.hs
- compiler/iface/IfaceSyn.hs
- compiler/llvmGen/LlvmCodeGen/CodeGen.hs
- compiler/main/InteractiveEval.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/f07b61d047967129a3ae0c56f8894d41c5a9b036...e1cc1254b81a7adadd8db77c7be625497264ab2b
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/f07b61d047967129a3ae0c56f8894d41c5a9b036...e1cc1254b81a7adadd8db77c7be625497264ab2b
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/20190405/cc1ef309/attachment-0001.html>
More information about the ghc-commits
mailing list