[Git][ghc/ghc][wip/T18566] 21 commits: Add HomeUnit type
Ben Gamari
gitlab at gitlab.haskell.org
Tue Sep 8 10:15:25 UTC 2020
Ben Gamari pushed to branch wip/T18566 at Glasgow Haskell Compiler / GHC
Commits:
ffc0d578 by Sylvain Henry at 2020-08-13T09:49:56-04:00
Add HomeUnit type
Since Backpack the "home unit" is much more involved than what it was
before (just an identifier obtained with `-this-unit-id`). Now it is
used in conjunction with `-component-id` and `-instantiated-with` to
configure module instantiations and to detect if we are type-checking an
indefinite unit or compiling a definite one.
This patch introduces a new HomeUnit datatype which is much easier to
understand. Moreover to make GHC support several packages in the same
instances, we will need to handle several HomeUnits so having a
dedicated (documented) type is helpful.
Finally in #14335 we will also need to handle the case where we have no
HomeUnit at all because we are only loading existing interfaces for
plugins which live in a different space compared to units used to
produce target code. Several functions will have to be refactored to
accept "Maybe HomeUnit" parameters instead of implicitly querying the
HomeUnit fields in DynFlags. Having a dedicated type will make this
easier.
Bump haddock submodule
- - - - -
8a51b2ab by Sylvain Henry at 2020-08-13T21:09:15-04:00
Make IOEnv monad one-shot (#18202)
On CI (x86_64-linux-deb9-hadrian, compile_time/bytes_allocated):
T10421 -1.8% (threshold: +/- 1%)
T10421a -1.7% (threshold: +/- 1%)
T12150 -4.9% (threshold: +/- 2%)
T12227 -1.6 (threshold: +/- 1%)
T12425 -1.5% (threshold: +/- 1%)
T12545 -3.8% (threshold: +/- 1%)
T12707 -3.0% (threshold: +/- 1%)
T13035 -3.0% (threshold: +/- 1%)
T14683 -10.3% (threshold: +/- 2%)
T3064 -6.9% (threshold: +/- 2%)
T4801 -4.3% (threshold: +/- 2%)
T5030 -2.6% (threshold: +/- 2%)
T5321FD -3.6% (threshold: +/- 2%)
T5321Fun -4.6% (threshold: +/- 2%)
T5631 -19.7% (threshold: +/- 2%)
T5642 -13.0% (threshold: +/- 2%)
T783 -2.7 (threshold: +/- 2%)
T9020 -11.1 (threshold: +/- 2%)
T9961 -3.4% (threshold: +/- 2%)
T1969 (compile_time/bytes_allocated) -2.2% (threshold: +/-1%)
T1969 (compile_time/max_bytes_used) +24.4% (threshold: +/-20%)
Additionally on other CIs:
haddock.Cabal -10.0% (threshold: +/- 5%)
haddock.compiler -9.5% (threshold: +/- 5%)
haddock.base (max bytes used) +24.6% (threshold: +/- 15%)
T10370 (max bytes used, i386) +18.4% (threshold: +/- 15%)
Metric Decrease:
T10421
T10421a
T12150
T12227
T12425
T12545
T12707
T13035
T14683
T3064
T4801
T5030
T5321FD
T5321Fun
T5631
T5642
T783
T9020
T9961
haddock.Cabal
haddock.compiler
Metric Decrease 'compile_time/bytes allocated':
T1969
Metric Increase 'compile_time/max_bytes_used':
T1969
T10370
haddock.base
- - - - -
9f66fdf6 by Ben Gamari at 2020-08-14T15:50:34-04:00
testsuite: Drop --io-manager flag from testsuite configuration
This is no longer necessary as there are now dedicated testsuite ways
which run tests with WinIO.
- - - - -
55fd1dc5 by Ben Gamari at 2020-08-14T15:51:10-04:00
llvm-targets: Add i686 targets
Addresses #18422.
- - - - -
f4cc57fa by Ben Gamari at 2020-08-18T15:38:55-04:00
Allow unsaturated runRW# applications
Previously we had a very aggressive Core Lint check which caught
unsaturated applications of runRW#. However, there is nothing
wrong with such applications and they may naturally arise in desugared
Core. For instance, the desugared Core of Data.Primitive.Array.runArray#
from the `primitive` package contains:
case ($) (runRW# @_ @_) (\s -> ...) of ...
In this case it's almost certain that ($) will be inlined, turning the
application into a saturated application. However, even if this weren't
the case there isn't a problem: CorePrep (after deleting an unnecessary
case) can simply generate code in its usual way, resulting in a call to
the Haskell definition of runRW#.
Fixes #18291.
- - - - -
3ac6ae7c by Ben Gamari at 2020-08-18T15:38:55-04:00
testsuite: Add test for #18291
- - - - -
a87a0b49 by Eli Schwartz at 2020-08-18T15:39:30-04:00
install: do not install sphinx doctrees
These files are 100% not needed at install time, and they contain
unreproducible info. See https://reproducible-builds.org/ for why this
matters.
- - - - -
194b25ee by Ben Gamari at 2020-08-18T15:40:05-04:00
testsuite: Allow baseline commit to be set explicitly
- - - - -
fdcf7645 by Ben Gamari at 2020-08-18T15:40:05-04:00
gitlab-ci: Use MR base commit as performance baseline
- - - - -
9ad5cab3 by Fendor at 2020-08-18T15:40:42-04:00
Expose UnitInfoMap as it is part of the public API
- - - - -
aa4b744d by Ben Gamari at 2020-08-18T22:11:36-04:00
testsuite: Only run llvm ways if llc is available
As noted in #18560, we previously would always run the LLVM ways since
`configure` would set `SettingsLlcCommand` to something non-null when
it otherwise couldn't find the `llc` executable. Now we rather probe for
the existence of the `llc` executable in the testsuite driver.
Fixes #18560.
- - - - -
0c5ed5c7 by Sylvain Henry at 2020-08-18T22:12:13-04:00
DynFlags: refactor GHC.CmmToAsm (#17957, #10143)
This patch removes the use of `sdocWithDynFlags` from GHC.CmmToAsm.*.Ppr
To do that I've had to make some refactoring:
* X86' and PPC's `Instr` are no longer `Outputable` as they require a
`Platform` argument
* `Instruction` class now exposes `pprInstr :: Platform -> instr -> SDoc`
* as a consequence, I've refactored some modules to avoid .hs-boot files
* added (derived) functor instances for some datatypes parametric in the
instruction type. It's useful for pretty-printing as we just have to
map `pprInstr` before pretty-printing the container datatype.
- - - - -
731c8d3b by nineonine at 2020-08-19T18:47:39-04:00
Implement -Wredundant-bang-patterns (#17340)
Add new flag '-Wredundant-bang-patterns' that enables checks for "dead" bangs.
Dead bangs are the ones that under no circumstances can force a thunk that
wasn't already forced. Dead bangs are a form of redundant bangs. The new check
is performed in Pattern-Match Coverage Checker along with other checks (namely,
redundant and inaccessible RHSs). Given
f :: Bool -> Int
f True = 1
f !x = 2
we can detect dead bang patterns by checking whether @x ~ ⊥@ is satisfiable
where the PmBang appears in 'checkGrdTree'. If not, then clearly the bang is
dead. Such a dead bang is then indicated in the annotated pattern-match tree by
a 'RedundantSrcBang' wrapping. In 'redundantAndInaccessibles', we collect
all dead bangs to warn about.
Note that we don't want to warn for a dead bang that appears on a redundant
clause. That is because in that case, we recommend to delete the clause wholly,
including its leading pattern match.
Dead bang patterns are redundant. But there are bang patterns which are
redundant that aren't dead, for example
f !() = 0
the bang still forces the match variable, before we attempt to match on (). But
it is redundant with the forcing done by the () match. We currently don't
detect redundant bangs that aren't dead.
- - - - -
eb9bdaef by Simon Peyton Jones at 2020-08-19T18:48:14-04:00
Add right-to-left rule for pattern bindings
Fix #18323 by adding a few lines of code to handle non-recursive
pattern bindings. see GHC.Tc.Gen.Bind
Note [Special case for non-recursive pattern bindings]
Alas, this confused the pattern-match overlap checker; see #18323.
Note that this patch only affects pattern bindings like that
for (x,y) in this program
combine :: (forall a . [a] -> a) -> [forall a. a -> a]
-> ((forall a . [a] -> a), [forall a. a -> a])
breaks = let (x,y) = combine head ids
in x y True
We need ImpredicativeTypes for those [forall a. a->a] types to be
valid. And with ImpredicativeTypes the old, unprincipled "allow
unification variables to unify with a polytype" story actually
works quite well. So this test compiles fine (if delicatedly) with
old GHCs; but not with QuickLook unless we add this patch
- - - - -
bbe81775 by Ben Gamari at 2020-08-21T19:25:18+00:00
IdInfo: Shrink arity fields to 20 bits
30 bits is utter overkill.
- - - - -
fd8f081a by Ben Gamari at 2020-08-21T19:25:18+00:00
IdInfo: Refactor bit packing logic and shrink arity fields
- - - - -
cdd88e58 by Ben Gamari at 2020-08-21T19:25:18+00:00
Rename addInlinePrags -> addIdPrags
This is going to be slightly generalized.
- - - - -
d019828b by Ben Gamari at 2020-08-21T19:25:18+00:00
Add CALLER_CC pragma
- - - - -
de2b9f80 by GHC GitLab CI at 2020-08-21T19:25:18+00:00
hii
- - - - -
458c1529 by GHC GitLab CI at 2020-08-29T16:06:23+00:00
Changes
- - - - -
e8a57252 by GHC GitLab CI at 2020-08-29T19:18:07+00:00
Merge it into the compiler
- - - - -
30 changed files:
- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC.hs
- compiler/GHC/Cmm.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/BlockLayout.hs
- compiler/GHC/CmmToAsm/Instr.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PIC.hs
- + compiler/GHC/CmmToAsm/PPC.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/Instr.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/Reg/Graph.hs
- compiler/GHC/CmmToAsm/Reg/Graph/SpillCost.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Stats.hs
- compiler/GHC/CmmToAsm/Reg/Linear.hs
- compiler/GHC/CmmToAsm/Reg/Linear/JoinToTargets.hs
- compiler/GHC/CmmToAsm/Reg/Linear/Stats.hs
- compiler/GHC/CmmToAsm/Reg/Liveness.hs
- + compiler/GHC/CmmToAsm/SPARC.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen/Expand.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen/Gen64.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen/Sanity.hs
- compiler/GHC/CmmToAsm/SPARC/Instr.hs
- compiler/GHC/CmmToAsm/SPARC/Ppr.hs
- + compiler/GHC/CmmToAsm/Types.hs
- + compiler/GHC/CmmToAsm/Utils.hs
- + compiler/GHC/CmmToAsm/X86.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e6c0d6b04f10c861066954fb3b2421f1d881720d...e8a572524d95a6dde3f382983ea302f5b13529c4
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e6c0d6b04f10c861066954fb3b2421f1d881720d...e8a572524d95a6dde3f382983ea302f5b13529c4
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/20200908/94c9b99c/attachment-0001.html>
More information about the ghc-commits
mailing list