[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 12 commits: docs: drop note about not supporting shared libraries on unix systems

Marge Bot gitlab at gitlab.haskell.org
Tue Apr 21 04:48:44 UTC 2020 


 Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
1e55dabf by Adam Sandberg Ericsson at 2020-04-21T00:48:21-04:00
docs: drop note about not supporting shared libraries on unix systems

[skip ci]

- - - - -
c01b636f by Sylvain Henry at 2020-04-21T00:48:23-04:00
Use ParserFlags in GHC.Runtime.Eval (#17957)

Instead of passing `DynFlags` to functions such as `isStmt` and
`hasImport` in `GHC.Runtime.Eval` we pass `ParserFlags`. It's a much
simpler structure that can be created purely with `mkParserFlags'`.

- - - - -
1abbb1a2 by Sylvain Henry at 2020-04-21T00:48:23-04:00
GHC.Runtime: avoid DynFlags (#17957)

* add `getPlatform :: TcM Platform` helper
* remove unused `DynFlags` parameter from `emptyPLS`

- - - - -
2c46a988 by Sylvain Henry at 2020-04-21T00:48:23-04:00
Avoid DynFlags in Ppr code (#17957)

* replace `DynFlags` parameters with `SDocContext` parameters for a few
  Ppr related functions: `bufLeftRenderSDoc`, `printSDoc`,
  `printSDocLn`, `showSDocOneLine`.

* remove the use of `pprCols :: DynFlags -> Int` in Outputable. We
  already have the information via `sdocLineLength :: SDocContext ->
  Int`

- - - - -
f6c78675 by Sylvain Henry at 2020-04-21T00:48:23-04:00
Avoid using sdocWithDynFlags (#17957)

Remove one use of `sdocWithDynFlags` from `GHC.CmmToLlvm.llvmCodeGen'`
and from `GHC.Driver.CodeOutput.profilingInitCode`

- - - - -
15723a0d by Sylvain Henry at 2020-04-21T00:48:23-04:00
Avoid `sdocWithDynFlags` in `pprCLbl` (#17957)

* add a `DynFlags` parameter to `pprCLbl`
* put `maybe_underscore` and `pprAsmCLbl` in a `where` clause to avoid
  `DynFlags` parameters

- - - - -
8062f7d5 by Sylvain Henry at 2020-04-21T00:48:23-04:00
CmmToAsm DynFlags refactoring (#17957)

* Remove `DynFlags` parameter from `isDynLinkName`: `isDynLinkName` used
  to test the global `ExternalDynamicRefs` flag. Now we test it outside of
  `isDynLinkName`

* Add new fields into `NCGConfig`: current unit id, sse/bmi versions,
  externalDynamicRefs, etc.

* Replace many uses of `DynFlags` by `NCGConfig`

* Moved `BMI/SSE` datatypes into `GHC.Platform`

- - - - -
8a6ca45a by Alexis King at 2020-04-21T00:48:24-04:00
Mark DataCon wrappers CONLIKE

Now that DataCon wrappers don’t inline until phase 0 (see commit
b78cc64e923716ac0512c299f42d4d0012306c05), it’s important that
case-of-known-constructor and RULE matching be able to see saturated
applications of DataCon wrappers in unfoldings. Making them conlike is a
natural way to do it, since they are, in fact, precisely the sort of
thing the CONLIKE pragma exists to solve.

Fixes #18012.

This also bumps the version of the parsec submodule to incorporate a
patch that avoids a metric increase on the haddock perf tests. The
increase was not really a flaw in this patch, as parsec was implicitly
relying on inlining heuristics. The patch to parsec just adds some
INLINABLE pragmas, and we get a nice performance bump out of it (well
beyond the performance we lost from this patch).

Metric Decrease:
    T12234
    WWRec
    haddock.Cabal
    haddock.base
    haddock.compiler

- - - - -
0e39d214 by Simon Peyton Jones at 2020-04-21T00:48:26-04:00
Do eager instantation in terms

This patch implements eager instantiation, a small but critical change
to the type inference engine, #17173.  The main change is this:

  When inferring types, always return an instantiated type
  (for now, deeply instantiated; in future shallowly instantiated)

There is more discussion in
https://www.tweag.io/posts/2020-04-02-lazy-eager-instantiation.html

There is quite a bit of refactoring in this patch:

* The ir_inst field of GHC.Tc.Utils.TcType.InferResultk
  has entirely gone.  So tcInferInst and tcInferNoInst have collapsed
  into tcInfer.

* Type inference of applications, via tcInferApp and
  tcInferAppHead, are substantially refactored, preparing
  the way for Quick Look impredicativity.

* New pure function GHC.Tc.Gen.Expr.collectHsArgs and applyHsArgs
  are beatifully dual.  We can see the zipper!

* GHC.Tc.Gen.Expr.tcArgs is now much nicer; no longer needs to return
  a wrapper

* In HsExpr, HsTypeApp now contains the the actual type argument,
  and is used in desugaring, rather than putting it in a mysterious
  wrapper.

* I struggled a bit with good error reporting in
  Unify.matchActualFunTysPart. It's a little bit simpler than before,
  but still not great.

Some smaller things

* Rename tcPolyExpr --> tcCheckExpr
         tcMonoExpr --> tcLExpr
* tcPatSig moves from GHC.Tc.Gen.HsType to GHC.Tc.Gen.Pat

Metric Decrease:
    T9961

Reduction of 1.6% in comiler allocation on T9961, I think.

- - - - -
0e2805c9 by Andreas Klebinger at 2020-04-21T00:48:27-04:00
Add "ddump-cmm-opt" as alias for "ddump-opt-cmm".

- - - - -
c4dc2796 by Sylvain Henry at 2020-04-21T00:48:29-04:00
MachO linker: display section name

- - - - -
226a9732 by Ben Gamari at 2020-04-21T00:48:30-04:00
llvmGen: Remove -fast-llvm flag

Issue #18076 drew my attention to the undocumented `-fast-llvm` flag for
the LLVM code generator introduced in
22733532171330136d87533d523f565f2a4f102f. Speaking to Moritz about this,
the motivation for this flag was to avoid potential incompatibilities
between LLVM and the assembler/linker toolchain by making LLVM
responsible for machine-code generation.

Unfortunately, this cannot possibly work: the LLVM backend's mangler
performs a number of transforms on the assembler generated by LLVM that
are necessary for correctness. These are currently:

 * mangling Haskell functions' symbol types to be `object` instead of
   `function` on ELF platforms (necessary for tables-next-to-code)
 * mangling AVX instructions to ensure that we don't assume alignment
   (which LLVM otherwise does)
 * mangling Darwin's  subsections-via-symbols directives

Given that these are all necessary I don't believe that we can support
`-fast-llvm`. Let's rather remove it.

- - - - -


30 changed files:

- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Info/Build.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/Config.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PIC.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToLlvm.hs
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/Driver/CodeOutput.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Packages.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Driver/Session.hs-boot
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/Rename/Splice.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Runtime/Heap/Inspect.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/Stg/Syntax.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Gen/Arrow.hs
- compiler/GHC/Tc/Gen/Bind.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3d402d556bd0e1d046d38cd4f33c73271fae3be0...226a97320f1a34173b96f6658b137c3a528ebd55

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3d402d556bd0e1d046d38cd4f33c73271fae3be0...226a97320f1a34173b96f6658b137c3a528ebd55
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/20200421/1bd921e8/attachment-0001.html>

More information about the ghc-commits mailing list