[commit: ghc] wip/T12618: Introduce ConApp to Core (2670589)
git at git.haskell.org
git at git.haskell.org
Thu Oct 13 19:24:38 UTC 2016
Repository : ssh://git@git.haskell.org/ghc
On branch : wip/T12618
Link : http://ghc.haskell.org/trac/ghc/changeset/2670589f2ff53bc04a7396489166a1f82445d2ec/ghc
>---------------------------------------------------------------
commit 2670589f2ff53bc04a7396489166a1f82445d2ec
Author: Joachim Breitner <mail at joachim-breitner.de>
Date: Thu Sep 29 16:56:56 2016 -0400
Introduce ConApp to Core
This is an all-commits-squashed commit, for the sake of testing this
branch on perf.haskell.org without testing the intermediate commits.
+ This is a combination of 58 commits.
+ The first commit's message is:
Introduce ConApp to Core (dead code as of yet)
This is the first step towards #12618: It adds the data constructor and
then fixes all problems due to incomplete patterns, essentially
preparing the complete compiler for the eventual use of this variant.
Because no where a ConApp is created, this should not yet have any
effect.
Care is taken to not take shortcuts via the data con worker id, as
eventually, there will be no data con worker any more.
There are a few unclear spots, marked with "TODO #12618". Input is
appreciated. These are currently:
* CoreLint: Remove a check from the App case that will only be relevant
occurring in the ConApp case later
* simplExprF1: This case became very easy. I might have overlooked
something else happening to arguments, as I read and simplified the
code that handled App. Second pairs of eyes welcome.
* ruleCheck: There can be no rules attached to data constructors, can
there?
* scExp: Can a datacon be in scSubstId?
* dmdAnal: How to get the idStrictness equivalent of the worker?
Or is there never something useful to be said about the strictness
signature of an constructor? (Because strictness annotations are
taken care of by the wrapper?
+ This is the 2nd commit message:
Actually desugar to ConApp
at least if the constructor is saturated. Fall back to the worker
otherwise.
+ This is the 3rd commit message:
ConApp bytecode: Add more ASSERT
+ This is the 4th commit message:
ConApp: Include dc worker id in free variables
just to see if this fixes the crashes here.
+ This is the 5th commit message:
ConApp: Include dc worker id in dffvExpr
just to see if this fixes the crashes here.
+ This is the 6th commit message:
mkDataConRep: Do not interleave applying arguments and unboxers
in preparation to using ConApp in the data con wrapper (where this is
not possible).
+ This is the 7th commit message:
DataCon wrapper: Use ConApp in the body
+ This is the 8th commit message:
mkCoreConApps: Warn about unsaturated use
+ This is the 9th commit message:
Lint: Complain about saturated uses of the data con worker
to find the spots where ConApp has to be used instead.
+ This is the 10th commit message:
Use ConApp in tagToEnumRule
+ This is the 11th commit message:
knownCon: Use ConApp in unfolding of scrutinee
+ This is the 12th commit message:
Get rid of unitDataConId (use ConApp instead)
+ This is the 13th commit message:
Always build a wrapper for data types
+ This is the 14th commit message:
Always use ConApp in CoreSyn
+ This is the 15th commit message:
Reserve a unique for the wrapper of a wired in DataCon
+ This is the 16th commit message:
CorePrep: Stop creating weird bindings for data constructor workers
as these should only occur saturated now.
+ This is the 17th commit message:
Desugar: Use Coercible worker, not wrapper
+ This is the 18th commit message:
Create a simple wrapper for built-in types as well
(The module structure might need some refactoring here.)
+ This is the 19th commit message:
Deserialize interface tuples to ConApp
+ This is the 20th commit message:
Handle ConApp in "Eliminate Identity Case"
+ This is the 21st commit message:
Use dataConWrapId in unsaturated uses of mkCoreConApps
+ This is the 22nd commit message:
ConApp: More Linting
+ This is the 23rd commit message:
mkSimpleDataConRep: No wrapper for newtypes
+ This is the 24th commit message:
mkCoreConApps: Do not use ConApp for newtypes
+ This is the 25th commit message:
New Lint Check: No data con workers any more, please
+ This is the 26th commit message:
Use ConApp when creating True resp. False
+ This is the 27th commit message:
Include constructor in freeNamesIfExpr
+ This is the 28th commit message:
isTrueLHsExpr: Match on data con wrapper now
+ This is the 29th commit message:
Temporarily disable rule shadowing warnings
Until https://ghc.haskell.org/trac/ghc/ticket/12618#comment:25 is
resolved.
+ This is the 30th commit message:
maybe_substitute: Detect ConApp
+ This is the 31st commit message:
Revert "CorePrep: Stop creating weird bindings for data constructor workers"
This reverts commit 36143d401423e7fc427cef6ed71cb9dae3c9d561.
+ This is the 32nd commit message:
Do not lint the bodz of the data con worker bindings introduced by CorePrep
+ This is the 33rd commit message:
coreToStgExpr: add con worker to free variables reported
+ This is the 34th commit message:
Handle ConApp in inlineBoringOk
+ This is the 35th commit message:
cpe_ExprIsTrivial: Nullary Constructors are trivial
+ This is the 36th commit message:
Handle nullary Cons in myCollectArgs
+ This is the 37th commit message:
Handle nullary constructors in the byte code generator.
+ This is the 38th commit message:
getIdFromTrivialExpr_maybe: Return dataConWorkId for nullary data cons
+ This is the 39th commit message:
Avoid invalid haddock synatx
+ This is the 40th commit message:
No lint warning about staticPtr data con worker
because of collectStaticPtrSatArgs this may be around.
+ This is the 41st commit message:
Update some test output
+ This is the 42nd commit message:
SetLevels: Do not float nullary data constructors
+ This is the 43rd commit message:
Update debugger test output
Because we desugare to the wrapper, without simplifiation, many
expressions that were values before are now thunks, and shown as such in
the debugger.
+ This is the 44th commit message:
Move zonking out of tcFamTyPats
In tcFamTyPats we were zonking from the TcType world to the
Type world, ready to build the results into a CoAxiom (which
should have no TcType stuff. But the 'thing_inside' for
tcFamTyPats also must be zonked, and that zonking must have
the ZonkEnv from the binders zonked tcFamTyPats.
Ugh. This caused an assertion failure (with DEBUG on) in
RaeBlobPost and TypeLevelVec, both in tests/dependent, as
shown in Trac #12682. Why it hasn't shown up before now
is obscure to me.
So I moved the zonking stuff out of tcFamTyPats to its
three call sites, where we can do it all together. Very
slightly longer, but much more robust.
+ This is the 45th commit message:
Nullary data constructors are trivial
+ This is the 46th commit message:
sptModuleInitCode: Look for ConApp
+ This is the 47th commit message:
Have a compulary unfolding for unboxed tuple wrappers
as we have no binding for them.
+ This is the 48th commit message:
Fix instance Eq (DeBruijn CoreExpr) for ConApp
+ This is the 49th commit message:
Adjust exprIsCheap
+ This is the 50th commit message:
SpecConstr.isValue: Handle ConApp
now all tests pass (here)
+ This is the 51st commit message:
Add test case for #12689
which test a few variants of rules involving constructors, including
nullary constructors, constructors with wrappers, and unsaturated of
constructors.
At the moment, all the rules work as expected, despite GHC’s compile
time warnings when called with -Wall.
+ This is the 52nd commit message:
Add a broken test case for #12689
A rule with a phase specification trying to match on a constructor with
a wrapper will fail to match, as the wrapper will be inlined by then.
The fact that it works in the other case is also mostly by accident.
(Split into two test cases so that regressions with regard what works so
far are caught.)
+ This is the 53rd commit message:
Make data con wrappers ConLike (and see what happens)
+ This is the 54th commit message:
Revert "Make data con wrappers ConLike (and see what happens)"
This reverts commit ad72aa0e46d1e58eac3e6ff3c17af080b01e6ff3.
+ This is the 55th commit message:
Use mkSimpleDataConRep in mkDataConRep if nothing fancy goes on
as a step towards treating them diffently in the inliner.
+ This is the 56th commit message:
Extend test for #12689 with rule matching late on normal data con
+ This is the 57th commit message:
Make simple DataCon wrappers complusary unfoldings
and make sure they are unfolded in simple_opt_expr, even when they are
nullary. For that, start paying attention to the arity field in the
unfolding guidance. (This design can be revised later.)
+ This is the 58th commit message:
Try to apply rules that match a data con
this is slightly annoying, all the rule matching code so far assumes
that rules can only apply to function applications, which is just no
longer true.
>---------------------------------------------------------------
2670589f2ff53bc04a7396489166a1f82445d2ec
compiler/basicTypes/DataCon.hs | 14 ++-
compiler/basicTypes/Demand.hs | 17 ++-
compiler/basicTypes/MkId.hs | 137 ++++++++++++++-------
compiler/basicTypes/MkId.hs-boot | 4 +-
compiler/basicTypes/Unique.hs | 22 ++--
compiler/codeGen/StgCmmEnv.hs | 1 -
compiler/coreSyn/CoreFVs.hs | 14 +++
compiler/coreSyn/CoreLint.hs | 42 +++++++
compiler/coreSyn/CorePrep.hs | 24 ++++
compiler/coreSyn/CoreSeq.hs | 1 +
compiler/coreSyn/CoreStats.hs | 2 +
compiler/coreSyn/CoreSubst.hs | 52 +++++---
compiler/coreSyn/CoreSyn.hs | 31 ++++-
compiler/coreSyn/CoreTidy.hs | 15 +--
compiler/coreSyn/CoreUnfold.hs | 20 ++-
compiler/coreSyn/CoreUtils.hs | 65 ++++++----
compiler/coreSyn/MkCore.hs | 39 +++++-
compiler/coreSyn/PprCore.hs | 10 ++
compiler/coreSyn/TrieMap.hs | 80 +++++++-----
compiler/deSugar/Desugar.hs | 5 +-
compiler/deSugar/DsBinds.hs | 10 +-
compiler/deSugar/DsCCall.hs | 6 +-
compiler/deSugar/DsListComp.hs | 8 +-
compiler/deSugar/DsUtils.hs | 4 +-
compiler/ghci/ByteCodeGen.hs | 42 ++++++-
compiler/iface/IfaceSyn.hs | 47 ++++---
compiler/iface/MkIface.hs | 27 ++--
compiler/iface/TcIface.hs | 7 +-
compiler/main/StaticPtrTable.hs | 5 +
compiler/main/TidyPgm.hs | 2 +
compiler/prelude/PrelNames.hs | 17 ++-
compiler/prelude/PrelRules.hs | 8 +-
compiler/prelude/TysWiredIn.hs | 35 +++---
compiler/simplCore/CSE.hs | 1 +
compiler/simplCore/CallArity.hs | 26 +++-
compiler/simplCore/FloatIn.hs | 19 +++
compiler/simplCore/FloatOut.hs | 8 ++
compiler/simplCore/LiberateCase.hs | 1 +
compiler/simplCore/OccurAnal.hs | 8 ++
compiler/simplCore/SAT.hs | 12 ++
compiler/simplCore/SetLevels.hs | 18 ++-
compiler/simplCore/SimplUtils.hs | 19 +--
compiler/simplCore/Simplify.hs | 30 ++++-
compiler/specialise/Rules.hs | 13 ++
compiler/specialise/SpecConstr.hs | 6 +
compiler/specialise/Specialise.hs | 3 +
compiler/stgSyn/CoreToStg.hs | 20 +++
compiler/stranal/DmdAnal.hs | 33 +++++
compiler/stranal/WorkWrap.hs | 3 +
compiler/typecheck/TcInstDcls.hs | 30 +++--
compiler/typecheck/TcTyClsDecls.hs | 48 +++++---
compiler/vectorise/Vectorise/Exp.hs | 13 ++
compiler/vectorise/Vectorise/Utils.hs | 6 -
mk/warnings.mk | 2 +
.../tests/deSugar/should_compile/T2431.stderr | 48 ++++----
.../tests/ghci.debugger/scripts/print002.stdout | 2 +-
.../tests/ghci.debugger/scripts/print003.stdout | 20 ++-
.../tests/ghci.debugger/scripts/print006.stdout | 14 +--
.../tests/ghci.debugger/scripts/print008.stdout | 10 +-
.../tests/ghci.debugger/scripts/print010.stdout | 7 +-
.../tests/ghci.debugger/scripts/print012.stdout | 9 +-
.../tests/ghci.debugger/scripts/print013.stdout | 2 +-
.../tests/ghci.debugger/scripts/print014.stdout | 2 +-
.../tests/ghci.debugger/scripts/print019.stderr | 12 +-
.../tests/ghci.debugger/scripts/print019.stdout | 15 +--
.../tests/ghci.debugger/scripts/print034.stdout | 6 +-
testsuite/tests/ghci/scripts/T2976.stdout | 2 +-
testsuite/tests/ghci/scripts/ghci055.stdout | 2 +-
.../tests/numeric/should_compile/T7116.stdout | 40 +++---
testsuite/tests/quasiquotation/T7918.stdout | 16 +--
testsuite/tests/roles/should_compile/Roles1.stderr | 60 ++++-----
.../tests/roles/should_compile/Roles13.stderr | 70 +++++------
.../tests/roles/should_compile/Roles14.stderr | 12 +-
testsuite/tests/roles/should_compile/Roles2.stderr | 20 +--
testsuite/tests/roles/should_compile/Roles3.stderr | 36 +++---
testsuite/tests/roles/should_compile/Roles4.stderr | 20 +--
testsuite/tests/roles/should_compile/T8958.stderr | 32 ++---
testsuite/tests/simplCore/should_compile/Makefile | 2 +-
.../tests/simplCore/should_compile/T3055.stdout | 2 +-
.../tests/simplCore/should_compile/T3234.stderr | 25 +++-
.../tests/simplCore/should_compile/T3717.stderr | 20 +--
.../tests/simplCore/should_compile/T3772.stdout | 22 ++--
.../tests/simplCore/should_compile/T3990.stdout | 2 +-
.../tests/simplCore/should_compile/T4908.stderr | 47 ++++---
.../tests/simplCore/should_compile/T4918.stdout | 4 +-
.../tests/simplCore/should_compile/T4930.stderr | 26 ++--
.../tests/simplCore/should_compile/T5366.stdout | 3 +-
.../tests/simplCore/should_compile/T7360.stderr | 114 ++++++++++-------
.../tests/simplCore/should_compile/T7865.stdout | 2 +-
.../tests/simplCore/should_compile/T8274.stdout | 34 +++--
.../tests/simplCore/should_compile/T8832.stdout | 20 +--
.../tests/simplCore/should_compile/T8848.stderr | 32 ++---
.../tests/simplCore/should_compile/T9400.stderr | 14 +--
.../tests/simplCore/should_compile/par01.stderr | 14 +--
.../tests/simplCore/should_compile/rule2.stderr | 19 ++-
.../simplCore/should_compile/spec-inline.stderr | 133 +++++++++++++-------
testsuite/tests/simplCore/should_run/T12689.hs | 33 +++++
testsuite/tests/simplCore/should_run/T12689.stdout | 8 ++
testsuite/tests/simplCore/should_run/T12689a.hs | 27 ++++
.../tests/simplCore/should_run/T12689a.stdout | 6 +
.../tests/simplCore/should_run/T12689broken.hs | 9 ++
.../tests/simplCore/should_run/T12689broken.stdout | 1 +
testsuite/tests/simplCore/should_run/all.T | 3 +
testsuite/tests/th/TH_Roles2.stderr | 8 +-
104 files changed, 1487 insertions(+), 732 deletions(-)
Diff suppressed because of size. To see it, use:
git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc 2670589f2ff53bc04a7396489166a1f82445d2ec
More information about the ghc-commits
mailing list