[Git][ghc/ghc][wip/T21694a] 18 commits: Implement Response File support for HPC
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Fri Aug 19 18:14:05 UTC 2022
Simon Peyton Jones pushed to branch wip/T21694a at Glasgow Haskell Compiler / GHC
Commits:
3e493dfd by Peter Becich at 2022-08-17T08:43:21+01:00
Implement Response File support for HPC
This is an improvement to HPC authored by Richard Wallace
(https://github.com/purefn) and myself. I have received permission from
him to attempt to upstream it. This improvement was originally
implemented as a patch to HPC via input-output-hk/haskell.nix:
https://github.com/input-output-hk/haskell.nix/pull/1464
Paraphrasing Richard, HPC currently requires all inputs as command line arguments.
With large projects this can result in an argument list too long error.
I have only seen this error in Nix, but I assume it can occur is a plain Unix environment.
This MR adds the standard response file syntax support to HPC. For
example you can now pass a file to the command line which contains the
arguments.
```
hpc @response_file_1 @response_file_2 ...
The contents of a Response File must have this format:
COMMAND ...
example:
report my_library.tix --include=ModuleA --include=ModuleB
```
Updates hpc submodule
Co-authored-by: Richard Wallace <rwallace at thewallacepack.net>
Fixes #22050
- - - - -
436867d6 by Matthew Pickering at 2022-08-18T09:24:08-04:00
ghc-heap: Fix decoding of TSO closures
An extra field was added to the TSO structure in 6d1700b6 but the
decoding logic in ghc-heap was not updated for this new field.
Fixes #22046
- - - - -
a740a4c5 by Matthew Pickering at 2022-08-18T09:24:44-04:00
driver: Honour -x option
The -x option is used to manually specify which phase a file should be
started to be compiled from (even if it lacks the correct extension). I
just failed to implement this when refactoring the driver.
In particular Cabal calls GHC with `-E -cpp -x hs Foo.cpphs` to
preprocess source files using GHC.
I added a test to exercise this case.
Fixes #22044
- - - - -
e293029d by Simon Peyton Jones at 2022-08-18T09:25:19-04:00
Be more careful in chooseInferredQuantifiers
This fixes #22065. We were failing to retain a quantifier that
was mentioned in the kind of another retained quantifier.
Easy to fix.
- - - - -
714c936f by Bryan Richter at 2022-08-18T18:37:21-04:00
testsuite: Add test for #21583
- - - - -
989b844d by Ben Gamari at 2022-08-18T18:37:57-04:00
compiler: Drop --build-id=none hack
Since 2011 the object-joining implementation has had a hack to pass
`--build-id=none` to `ld` when supported, seemingly to work around a
linker bug. This hack is now unnecessary and may break downstream users
who expect objects to have valid build-ids. Remove it.
Closes #22060.
- - - - -
519c712e by Matthew Pickering at 2022-08-19T00:09:11-04:00
Make ru_fn field strict to avoid retaining Ids
It's better to perform this projection from Id to Name strictly so we
don't retain an old Id (hence IdInfo, hence Unfolding, hence everything
etc)
- - - - -
7dda04b0 by Matthew Pickering at 2022-08-19T00:09:11-04:00
Force `getOccFS bndr` to avoid retaining reference to Bndr.
This is another symptom of #19619
- - - - -
4303acba by Matthew Pickering at 2022-08-19T00:09:11-04:00
Force unfoldings when they are cleaned-up in Tidy and CorePrep
If these thunks are not forced then the entire unfolding for the binding
is live throughout the whole of CodeGen despite the fact it should have
been discarded.
Fixes #22071
- - - - -
2361b3bc by Matthew Pickering at 2022-08-19T00:09:47-04:00
haddock docs: Fix links from identifiers to dependent packages
When implementing the base_url changes I made the pretty bad mistake of
zipping together two lists which were in different orders. The simpler
thing to do is just modify `haddockDependencies` to also return the
package identifier so that everything stays in sync.
Fixes #22001
- - - - -
9a7e2ea1 by Matthew Pickering at 2022-08-19T00:10:23-04:00
Revert "Refactor SpecConstr to use treat bindings uniformly"
This reverts commit 415468fef8a3e9181b7eca86de0e05c0cce31729.
This refactoring introduced quite a severe residency regression (900MB
live from 650MB live when compiling mmark), see #21993 for a reproducer
and more discussion.
Ticket #21993
- - - - -
69dc6973 by Simon Peyton Jones at 2022-08-19T19:13:21+01:00
Fix arityType: -fpedantic-bottoms, join points, etc
This MR fixes #21694 and #21755
* For #21694 the underlying problem was that we were calling arityType
on an expression that had free join points. This is a Bad Bad Idea.
See Note [No free join points in arityType].
* I also made andArityType work correctly with -fpedantic-bottoms;
see Note [Combining case branches: andWithTail].
* I realised that, now we have ae_sigs giving the ArityType for
let-bound Ids, we don't need the (pre-dating) special code in
arityType for join points. But instead we need to extend the env for
Rec bindings, which weren't doing before. More uniform now. See
Note [arityType for let-bindings].
This meant we could get rid of ae_joins, and in fact get rid of
EtaExpandArity altogether. Simpler.
And finally, it was the strange treatment of join-point Ids (involving
a fake ABot type) that led to a serious bug: #21755. Fixed by this
refactoring
* Rewrote Note [Combining case branches: optimistic one-shot-ness]
Compile time improves slightly on average:
Metrics: compile_time/bytes allocated
---------------------------------------------------------------------------------------
CoOpt_Read(normal) ghc/alloc 803,788,056 747,832,680 -7.1% GOOD
T18223(normal) ghc/alloc 928,207,320 959,424,016 +3.1% BAD
geo. mean -0.3%
minimum -7.1%
maximum +3.1%
On Windows it's a bit better: geo mean is -0.6%, and three more
benchmarks trip their compile-time bytes-allocated threshold (they
were all close on the other build):
T18698b(normal) ghc/alloc 235,619,776 233,219,008 -1.0% GOOD
T6048(optasm) ghc/alloc 112,208,192 109,704,936 -2.2% GOOD
T18140(normal) ghc/alloc 85,064,192 83,168,360 -2.2% GOOD
I had a quick look at T18223 but it is knee deep in coercions and
the size of everything looks similar before and after. I decided
to accept that 3.4% increase in exchange for goodness elsewhere.
Metric Decrease:
CoOpt_Read
T18140
T18698b
T6048
Metric Increase:
T18223
- - - - -
4dbcdf8d by Simon Peyton Jones at 2022-08-19T19:13:21+01:00
Try giving join points proper ArityInfo
work in progress
- - - - -
0d080b71 by Simon Peyton Jones at 2022-08-19T19:13:21+01:00
Further wibbles
- - - - -
54cb64ca by Simon Peyton Jones at 2022-08-19T19:13:21+01:00
Wibble worker/wrapper for join points
Need to add docs
- - - - -
439dc397 by Simon Peyton Jones at 2022-08-19T19:13:21+01:00
Efficency improvements
Don't call full arityType for non-rec join points
(must document this).
Refactoring
- - - - -
50ca5069 by Simon Peyton Jones at 2022-08-19T19:13:21+01:00
Improve exprIsDeadEnd
- - - - -
b65e1d6c by Simon Peyton Jones at 2022-08-19T19:13:56+01:00
Remove unused import
- - - - -
30 changed files:
- compiler/GHC/Core.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatOut.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/WorkWrap.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Driver/Pipeline/Monad.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Settings.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Types/Var.hs
- hadrian/bindist/Makefile
- hadrian/cfg/system.config.in
- hadrian/src/Rules/Documentation.hs
- hadrian/src/Rules/Generate.hs
- hadrian/src/Settings/Builders/Haddock.hs
- libraries/ghc-heap/GHC/Exts/Heap.hs
- libraries/ghc-heap/GHC/Exts/Heap/Closures.hs
- libraries/hpc
- − m4/fp_prog_ld_build_id.m4
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d22bec7cdb9ff5ac9d9a496954a09f084aaa12a6...b65e1d6c237e4399b618c8087d7df043acd57826
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d22bec7cdb9ff5ac9d9a496954a09f084aaa12a6...b65e1d6c237e4399b618c8087d7df043acd57826
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/20220819/dd812b77/attachment-0001.html>
More information about the ghc-commits
mailing list