[Git][ghc/ghc][wip/fragile-T7919] 19 commits: Tidy implicit binds

Bryan R (@chreekat) gitlab at gitlab.haskell.org
Wed Oct 12 06:47:38 UTC 2022 


Bryan R pushed to branch wip/fragile-T7919 at Glasgow Haskell Compiler / GHC


Commits:
fbb88740 by Matthew Pickering at 2022-10-11T12:48:45-04:00
Tidy implicit binds

We want to put implicit binds into fat interface files, so the easiest
thing to do seems to be to treat them uniformly with other binders.

- - - - -
e058b138 by Matthew Pickering at 2022-10-11T12:48:45-04:00
Interface Files with Core Definitions

This commit adds three new flags

* -fwrite-if-simplified-core: Writes the whole core program into an interface
  file
* -fbyte-code-and-object-code: Generate both byte code and object code
  when compiling a file
* -fprefer-byte-code: Prefer to use byte-code if it's available when
  running TH splices.

The goal for including the core bindings in an interface file is to be able to restart the compiler pipeline
at the point just after simplification and before code generation. Once compilation is
restarted then code can be created for the byte code backend.
This can significantly speed up
start-times for projects in GHCi. HLS already implements its own version of these extended interface
files for this reason.

Preferring to use byte-code means that we can avoid some potentially
expensive code generation steps (see #21700)

* Producing object code is much slower than producing bytecode, and normally you
  need to compile with `-dynamic-too` to produce code in the static and dynamic way, the
  dynamic way just for Template Haskell execution when using a dynamically linked compiler.

* Linking many large object files, which happens once per splice, can be quite
  expensive compared to linking bytecode.

And you can get GHC to compile the necessary byte code so
`-fprefer-byte-code` has access to it by using
`-fbyte-code-and-object-code`.

Fixes #21067

- - - - -
9789ea8e by Matthew Pickering at 2022-10-11T12:48:45-04:00
Teach -fno-code about -fprefer-byte-code

This patch teachs the code generation logic of -fno-code about
-fprefer-byte-code, so that if we need to generate code for a module
which prefers byte code, then we generate byte code rather than object
code.

We keep track separately which modules need object code and which byte
code and then enable the relevant code generation for each. Typically
the option will be enabled globally so one of these sets should be empty
and we will just turn on byte code or object code generation.

We also fix the bug where we would generate code for a module which
enables Template Haskell despite the fact it was unecessary.

Fixes #22016

- - - - -
caced757 by Simon Peyton Jones at 2022-10-11T12:49:21-04:00
Don't keep exit join points so much

We were religiously keeping exit join points throughout, which
had some bad effects (#21148, #22084).

This MR does two things:

* Arranges that exit join points are inhibited from inlining
  only in /one/ Simplifier pass (right after Exitification).

  See Note [Be selective about not-inlining exit join points]
  in GHC.Core.Opt.Exitify

  It's not a big deal, but it shaves 0.1% off compile times.

* Inline used-once non-recursive join points very aggressively
  Given join j x = rhs in
        joinrec k y = ....j x....

  where this is the only occurrence of `j`, we want to inline `j`.
  (Unless sm_keep_exits is on.)

  See Note [Inline used-once non-recursive join points] in
  GHC.Core.Opt.Simplify.Utils

  This is just a tidy-up really.  It doesn't change allocation, but
  getting rid of a binding is always good.

Very effect on nofib -- some up and down.

- - - - -
284cf387 by Simon Peyton Jones at 2022-10-11T12:49:21-04:00
Make SpecConstr bale out less often

When doing performance debugging on #22084 / !8901, I found that the
algorithm in SpecConstr.decreaseSpecCount was so aggressive that if
there were /more/ specialisations available for an outer function,
that could more or less kill off specialisation for an /inner/
function.  (An example was in nofib/spectral/fibheaps.)

This patch makes it a bit more aggressive, by dividing by 2, rather
than by the number of outer specialisations.

This makes the program bigger, temporarily:

   T19695(normal) ghc/alloc   +11.3% BAD

because we get more specialisation.  But lots of other programs
compile a bit faster and the geometric mean in perf/compiler
is 0.0%.

Metric Increase:
    T19695

- - - - -
66af1399 by Cheng Shao at 2022-10-11T12:49:59-04:00
CmmToC: emit explicit tail calls when the C compiler supports it

Clang 13+ supports annotating a return statement using the musttail
attribute, which guarantees that it lowers to a tail call if compilation
succeeds.

This patch takes advantage of that feature for the unregisterised code
generator. The configure script tests availability of the musttail
attribute, if it's available, the Cmm tail calls will become C tail
calls that avoids the mini interpreter trampoline overhead. Nothing is
affected if the musttail attribute is not supported.

Clang documentation:
https://clang.llvm.org/docs/AttributeReference.html#musttail

- - - - -
7f0decd5 by Matthew Pickering at 2022-10-11T12:50:40-04:00
Don't include BufPos in interface files

Ticket #22162 pointed out that the build directory was leaking into the
ABI hash of a module because the BufPos depended on the location of the
build tree.

BufPos is only used in GHC.Parser.PostProcess.Haddock, and the
information doesn't need to be propagated outside the context of a
module.

Fixes #22162

- - - - -
dce9f320 by Cheng Shao at 2022-10-11T12:51:19-04:00
CLabel: fix isInfoTableLabel

isInfoTableLabel does not take Cmm info table into account. This patch is required for data section layout of wasm32 NCG to work.

- - - - -
da679f2e by Bodigrim at 2022-10-11T18:02:59-04:00
Extend documentation for Data.List, mostly wrt infinite lists

- - - - -
9c099387 by jwaldmann at 2022-10-11T18:02:59-04:00
Expand comment for Data.List.permutations
- - - - -
d3863cb7 by Bodigrim at 2022-10-11T18:03:37-04:00
ByteArray# is unlifted, not unboxed

- - - - -
f6260e8b by Ben Gamari at 2022-10-11T23:45:10-04:00
rts: Add missing declaration of stg_noDuplicate

- - - - -
69ccec2c by Ben Gamari at 2022-10-11T23:45:10-04:00
base: Move CString, CStringLen to GHC.Foreign

- - - - -
f6e8feb4 by Ben Gamari at 2022-10-11T23:45:10-04:00
base: Move IPE helpers to GHC.InfoProv

- - - - -
866c736e by Ben Gamari at 2022-10-11T23:45:10-04:00
rts: Refactor IPE tracing support

- - - - -
6b0d2022 by Ben Gamari at 2022-10-11T23:45:10-04:00
Refactor IPE initialization

Here we refactor the representation of info table provenance information
in object code to significantly reduce its size and link-time impact.
Specifically, we deduplicate strings and represent them as 32-bit
offsets into a common string table.

In addition, we rework the registration logic to eliminate allocation
from the registration path, which is run from a static initializer where
things like allocation are technically undefined behavior (although it
did previously seem to work). For similar reasons we eliminate lock
usage from registration path, instead relying on atomic CAS.

Closes #22077.

- - - - -
9b572d54 by Ben Gamari at 2022-10-11T23:45:10-04:00
Separate IPE source file from span

The source file name can very often be shared across many IPE entries
whereas the source coordinates are generally unique. Separate the two to
exploit sharing of the former.

- - - - -
27978ceb by Krzysztof Gogolewski at 2022-10-11T23:45:46-04:00
Make Cmm Lint messages use dump style

Lint errors indicate an internal error in GHC, so it makes sense to use
it instead of the user style. This is consistent with Core Lint and STG Lint:

https://gitlab.haskell.org/ghc/ghc/-/blob/22096652/compiler/GHC/Core/Lint.hs#L429

https://gitlab.haskell.org/ghc/ghc/-/blob/22096652/compiler/GHC/Stg/Lint.hs#L144

Fixes #22218.

- - - - -
5614b0c4 by Bryan Richter at 2022-10-12T09:47:22+03:00
Mark T7919 as fragile

On x86_64-linux, T7919 timed out ~30 times during July 2022.

- - - - -


30 changed files:

- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/X86/Ppr.hs
- compiler/GHC/Core/Opt/Exitify.hs
- compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/CodeOutput.hs
- compiler/GHC/Driver/Config/Core/Opt/Simplify.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Driver/Pipeline/Phases.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Linker/Loader.hs
- compiler/GHC/Linker/Types.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5072e6c34af3e526476b17320614193061845b3b...5614b0c41863ef33f7e8ea42dfeedfe17b09aead

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5072e6c34af3e526476b17320614193061845b3b...5614b0c41863ef33f7e8ea42dfeedfe17b09aead
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/20221012/ef4caf34/attachment-0001.html>

More information about the ghc-commits mailing list