[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 14 commits: Compute demand signatures assuming idArity
Marge Bot
gitlab at gitlab.haskell.org
Tue Apr 30 20:33:11 UTC 2019
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
6b978b7f by Sebastian Graf at 2019-04-30T20:32:52Z
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%
reptile -0.0% -1.2%
--------------------------------------------------------------------------------
Min -0.0% -1.2%
Max +0.3% +0.8%
Geometric Mean +0.0% -0.0%
- - - - -
34142546 by John Ericson at 2019-04-30T20:32:53Z
Generate settings by make/hadrian instead of configure
This allows it to eventually become stage-specific
- - - - -
46491a40 by John Ericson at 2019-04-30T20:32:53Z
Remove settings.in
It is no longer needed
- - - - -
3ba652ce by John Ericson at 2019-04-30T20:32:53Z
Move cGHC_UNLIT_PGM to be "unlit command" in settings
The bulk of the work was done in #712, making settings be make/Hadrian
controlled. This commit then just moves the unlit command rules in
make/Hadrian from the `Config.hs` generator to the `settings` generator
in each build system.
I think this is a good change because the crucial benefit is *settings*
don't affect the build: ghc gets one baby step closer to being a regular
cabal executable, and make/Hadrian just maintains settings as part of
bootstrapping.
- - - - -
0c5143e2 by Alp Mestanogullari at 2019-04-30T20:32:56Z
Build Hadrian with -Werror in the 'ghc-in-ghci' CI job
- - - - -
d12ec2e1 by Ben Gamari at 2019-04-30T20:32:56Z
ErrUtils: Emit progress messages to eventlog
- - - - -
f650c290 by Ben Gamari at 2019-04-30T20:32:56Z
Emit GHC timing events to eventlog
- - - - -
e0193219 by Chaitanya Koparkar at 2019-04-30T20:32:59Z
Fix #16593 by having only one definition of -fprint-explicit-runtime-reps
[skip ci]
- - - - -
261bc9c6 by Sven Tennie at 2019-04-30T20:33:01Z
Typeset Big-O complexities with Tex-style notation (#16090)
Use `\min` instead of `min` to typeset it as an operator.
- - - - -
e6b1c1d3 by Shayne Fletcher at 2019-04-30T20:33:03Z
Make Extension derive Bounded
- - - - -
c4af2cfd by Ben Gamari at 2019-04-30T20:33:03Z
testsuite: Mark concprog001 as fragile
Due to #16604.
- - - - -
a92cbac2 by Alp Mestanogullari at 2019-04-30T20:33:05Z
Hadrian: generate JUnit testsuite report in Linux CI job
We also keep it as an artifact, like we do for non-Hadrian jobs, and list it
as a junit report, so that the test results are reported in the GitLab UI for
merge requests.
- - - - -
595d4729 by Vladislav Zavialov at 2019-04-30T20:33:05Z
Pattern/expression ambiguity resolution
This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
from 'HsExpr' by using the ambiguity resolution system introduced
earlier for the command/expression ambiguity.
Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a pattern, for example:
do { Con a b <- x } -- 'Con a b' is a pattern
do { Con a b } -- 'Con a b' is an expression
Until we encounter binding syntax (<-) we don't know whether to parse
'Con a b' as an expression or a pattern.
The old solution was to parse as HsExpr always, and rejig later:
checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)
This meant polluting 'HsExpr' with pattern-related constructors. In
other words, limitations of the parser were affecting the AST, and all
other code (the renamer, the typechecker) had to deal with these extra
constructors.
We fix this abstraction leak by parsing into an overloaded
representation:
class DisambECP b where ...
newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }
See Note [Ambiguous syntactic categories] for details.
Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/pattern ambiguity.
- - - - -
1c8d64ba by Ömer Sinan Ağacan at 2019-04-30T20:33:09Z
Fix interface version number printing in --show-iface
Before
Version: Wanted [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5],
got [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5]
After
Version: Wanted 809020190425,
got 809020190425
- - - - -
24 changed files:
- .gitlab-ci.yml
- aclocal.m4
- compiler/basicTypes/Demand.hs
- compiler/basicTypes/Id.hs
- compiler/basicTypes/IdInfo.hs
- compiler/basicTypes/Var.hs
- compiler/coreSyn/CoreArity.hs
- compiler/coreSyn/CoreLint.hs
- compiler/coreSyn/CoreUnfold.hs
- compiler/deSugar/DsExpr.hs
- compiler/ghc.mk
- compiler/hieFile/HieAst.hs
- compiler/hsSyn/HsExpr.hs
- compiler/hsSyn/HsExtension.hs
- compiler/iface/BinIface.hs
- compiler/main/ErrUtils.hs
- compiler/main/SysTools.hs
- compiler/parser/Lexer.x
- compiler/parser/Parser.y
- compiler/parser/RdrHsSyn.hs
- compiler/rename/RnExpr.hs
- compiler/simplCore/SimplMonad.hs
- compiler/simplCore/SimplUtils.hs
- compiler/stranal/DmdAnal.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/7c7eb687a18cd6f2cb53a85096faae3cfc8e6676...1c8d64baf782daafe797cf48c73a61809cdcef2c
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/7c7eb687a18cd6f2cb53a85096faae3cfc8e6676...1c8d64baf782daafe797cf48c73a61809cdcef2c
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/20190430/20c3d04d/attachment.html>
More information about the ghc-commits
mailing list