[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 30 commits: base: Add Generic instances to various datatypes under GHC.*

Marge Bot gitlab at gitlab.haskell.org
Thu May 21 03:48:26 UTC 2020 


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


Commits:
981bc673 by Fumiaki Kinoshita at 2020-05-20T23:47:40-04:00
base: Add Generic instances to various datatypes under GHC.*

* GHC.Fingerprint.Types: Fingerprint
* GHC.RTS.Flags: GiveGCStats, GCFlags, ConcFlags, DebugFlags, CCFlags, DoHeapProfile, ProfFlags, DoTrace, TraceFlags, TickyFlags, ParFlags and RTSFlags
* GHC.Stats: RTSStats and GCStats
* GHC.ByteOrder: ByteOrder
* GHC.Unicode: GeneralCategory
* GHC.Stack.Types: SrcLoc

Metric Increase:
    haddock.base

- - - - -
365c1f1f by Gert-Jan Bottu at 2020-05-20T23:47:41-04:00
Explicit Specificity

Implementation for Ticket #16393.
Explicit specificity allows users to manually create inferred type variables,
by marking them with braces.
This way, the user determines which variables can be instantiated through
visible type application.

The additional syntax is included in the parser, allowing users to write
braces in type variable binders (type signatures, data constructors etc).
This information is passed along through the renamer and verified in the
type checker.
The AST for type variable binders, data constructors, pattern synonyms,
partial signatures and Template Haskell has been updated to include the
specificity of type variables.

Minor notes:
- Bumps haddock submodule
- Disables pattern match checking in GHC.Iface.Type with GHC 8.8

- - - - -
ab99955b by Ben Price at 2020-05-20T23:47:44-04:00
Lint should say when it is checking a rule

It is rather confusing that when lint finds an error in a rule attached
to a binder, it reports the error as in the RHS, not the rule:
  ...
  In the RHS of foo

We add a clarifying line:
  ...
  In the RHS of foo
  In a rule attached to foo

The implication that the rule lives inside the RHS is a bit odd, but
this niggle is already present for unfoldings, whose pattern we are
following.

- - - - -
8b17749b by Ben Gamari at 2020-05-20T23:47:45-04:00
nonmoving: Optimise the write barrier

- - - - -
7df648d7 by Andreas Klebinger at 2020-05-20T23:47:46-04:00
Refactor linear reg alloc to remember past assignments.

When assigning registers we now first try registers we
assigned to in the past, instead of picking the "first"
one.

This is in extremely helpful when dealing with loops for
which variables are dead for part of the loop.

This is important for patterns like this:

        foo = arg1
    loop:
        use(foo)
        ...
        foo = getVal()
        goto loop;

There we:
* assign foo to the register of arg1.
* use foo, it's dead after this use as it's overwritten after.
* do other things.
* look for a register to put foo in.

If we pick an arbitrary one it might differ from the register the
start of the loop expect's foo to be in.
To fix this we simply look for past register assignments for
the given variable. If we find one and the register is free we
use that register.

This reduces the need for fixup blocks which match the register
assignment between blocks. In the example above between the end
and the head of the loop.

This patch also moves branch weight estimation ahead of register
allocation and adds a flag to control it (cmm-static-pred).
* It means the linear allocator is more likely to assign the hotter
  code paths first.
* If it assign these first we are:
  + Less likely to spill on the hot path.
  + Less likely to introduce fixup blocks on the hot path.

These two measure combined are surprisingly effective. Based on nofib
we get in the mean:

* -0.9% instructions executed
* -0.1% reads/writes
* -0.2% code size.
* -0.1% compiler allocations.
* -0.9% compile time.
* -0.8% runtime.

Most of the benefits are simply a result of removing redundant moves
and spills.

Reduced compiler allocations likely are the result of less code being
generated. (The added lookup is mostly non-allocating).

- - - - -
f9f62e62 by Andreas Klebinger at 2020-05-20T23:47:47-04:00
NCG: Codelayout: Distinguish conditional and other branches.

In #18053 we ended up with a suboptimal code layout because
the code layout algorithm didn't distinguish between conditional
and unconditional control flow.

We can completely eliminate unconditional control flow instructions
by placing blocks next to each other, not so much for conditionals.

In terms of implementation we simply give conditional branches less
weight before computing the layout.

Fixes #18053

- - - - -
ae4d3378 by Gleb Popov at 2020-05-20T23:47:49-04:00
gitlab-ci: Set locale to C.UTF-8.

- - - - -
509efa3e by Stefan Holdermans at 2020-05-20T23:47:51-04:00
Allow spaces in GHCi :script file names

This patch updates the user interface of GHCi so that file names passed
to the ':script' command may contain spaces escaped with a backslash.

For example:

  :script foo\ bar.script

The implementation uses a modified version of 'words' that does not
break on escaped spaces.

Fixes #18027.

- - - - -
eac7f5a9 by Stefan Holdermans at 2020-05-20T23:47:51-04:00
Add extra tests for GHCi :script syntax checks

The syntax for GHCi's ":script" command allows for only a single file
name to be passed as an argument. This patch adds a test for the cases
in which a file name is missing or multiple file names are passed.

Related to #T18027.

- - - - -
96fc852a by Stefan Holdermans at 2020-05-20T23:47:51-04:00
Allow GHCi :script file names in double quotes

This patch updates the user interface of GHCi so that file names passed
to the ':script' command can be wrapped in double quotes.

For example:

  :script "foo bar.script"

The implementation uses a modified version of 'words' that treats
character sequences enclosed in double quotes as single words.

Fixes #18027.

- - - - -
1cbb1fac by Stefan Holdermans at 2020-05-20T23:47:51-04:00
Update documentation for GHCi :script

This patch adds the fixes that allow for file names containing spaces to
be passed to GHCi's ':script' command to the release notes for 8.12 and
expands the user-guide documentation for ':script' by mentioning how
such file names can be passed.

Related to #18027.

- - - - -
abdf338c by Tuan Le at 2020-05-20T23:47:52-04:00
llvmGen: Consider Relocatable read-only data as not constantReferences: #18137

- - - - -
ce449c2c by John Ericson at 2020-05-20T23:47:53-04:00
Use `Checker` for `tc_pat`

- - - - -
66d5ce74 by John Ericson at 2020-05-20T23:47:53-04:00
Use `Checker` for `tc_lpat` and `tc_lpats`

- - - - -
6418d5c2 by John Ericson at 2020-05-20T23:47:53-04:00
More judiciously panic in `ts_pat`

- - - - -
5303f161 by John Ericson at 2020-05-20T23:47:53-04:00
Put `PatEnv` first in `GHC.Tc.Gen.Pat.Checker`

- - - - -
e366dc56 by John Ericson at 2020-05-20T23:47:53-04:00
Tiny cleaup eta-reduce away a function argument

In GHC, not in the code being compiled!

- - - - -
58534dc4 by John Ericson at 2020-05-20T23:47:53-04:00
Use braces with do in `SplicePat` case for consistency

- - - - -
55e2f9f5 by buggymcbugfix at 2020-05-20T23:47:54-04:00
Fix spelling mistakes and typos

- - - - -
40b4f3fd by buggymcbugfix at 2020-05-20T23:47:54-04:00
Add INLINABLE pragmas to Enum list producers

The INLINABLE pragmas ensure that we export stable (unoptimised) unfoldings in
the interface file so we can do list fusion at usage sites.

Related tickets: #15185, #8763, #18178.

- - - - -
5f11cb50 by buggymcbugfix at 2020-05-20T23:47:54-04:00
Piggyback on Enum Word methods for Word64

If we are on a 64 bit platform, we can use the efficient Enum Word
methods for the Enum Word64 instance.

- - - - -
9f5b1b69 by buggymcbugfix at 2020-05-20T23:47:54-04:00
Document INLINE(ABLE) pragmas that enable fusion

- - - - -
042e9fdb by Richard Eisenberg at 2020-05-20T23:47:54-04:00
MR template should ask for key part
- - - - -
fae4e4d8 by Sebastian Graf at 2020-05-20T23:47:55-04:00
Make `Int`'s `mod` and `rem` strict in their first arguments

They used to be strict until 4d2ac2d (9 years ago).

It's obviously better to be strict for performance reasons.
It also blocks #18067.

NoFib results:

```
--------------------------------------------------------------------------------
        Program         Allocs    Instrs
--------------------------------------------------------------------------------
        integer          -1.1%     +0.4%
   wheel-sieve2         +21.2%    +20.7%
--------------------------------------------------------------------------------
            Min          -1.1%     -0.0%
            Max         +21.2%    +20.7%
 Geometric Mean          +0.2%     +0.2%
```

The regression in `wheel-sieve2` is due to reboxing that likely will go
away with the resolution of #18067. See !3282 for details.

Fixes #18187.

- - - - -
d073c2b4 by Galen Huntington at 2020-05-20T23:47:59-04:00
Clarify pitfalls of NegativeLiterals; see #18022.
- - - - -
5a0742e3 by Alexey Kuleshevich at 2020-05-20T23:48:01-04:00
Fix wording in primops documentation to reflect the correct reasoning:

* Besides resizing functions, shrinking ones also mutate the
  size of a mutable array and because of those two `sizeofMutabeByteArray`
  and `sizeofSmallMutableArray` are now deprecated
* Change reference in documentation to the newer functions `getSizeof*`
  instead of `sizeof*` for shrinking functions
* Fix incorrect mention of "byte" instead of "small"

- - - - -
59055975 by Andreas Klebinger at 2020-05-20T23:48:01-04:00
Don't variable-length encode magic iface constant.

We changed to use variable length encodings for many types by default,
including Word32. This makes sense for numbers but not when Word32 is
meant to represent four bytes.

I added a FixedLengthEncoding newtype to Binary who's instances
interpret their argument as a collection of bytes instead of a number.

We then use this when writing/reading magic numbers to the iface file.

I also took the libery to remove the dummy iface field.

This fixes #18180.

- - - - -
5f5a625b by Krzysztof Gogolewski at 2020-05-20T23:48:02-04:00
Add a regression test for #11506

The testcase works now.
See explanation in https://gitlab.haskell.org/ghc/ghc/issues/11506#note_273202

- - - - -
db013fcd by Krzysztof Gogolewski at 2020-05-20T23:48:04-04:00
Sort deterministically metric output

Previously, we sorted according to the test name and way,
but the metrics (max_bytes_used/peak_megabytes_allocated etc.)
were appearing in nondeterministic order.

- - - - -
c2aeb010 by Sylvain Henry at 2020-05-20T23:48:06-04:00
Move isDynLinkName into GHC.Types.Name

It doesn't belong into GHC.Unit.State

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- .gitlab/merge_request_templates/merge-request.md
- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/BlockLayout.hs
- compiler/GHC/CmmToAsm/CFG.hs
- compiler/GHC/CmmToAsm/Instr.hs
- compiler/GHC/CmmToAsm/Reg/Linear.hs
- compiler/GHC/CmmToAsm/Reg/Linear/Base.hs
- compiler/GHC/CmmToAsm/Reg/Linear/PPC.hs
- compiler/GHC/CmmToAsm/Reg/Linear/SPARC.hs
- compiler/GHC/CmmToAsm/Reg/Linear/State.hs
- compiler/GHC/CmmToAsm/Reg/Linear/X86.hs
- compiler/GHC/CmmToAsm/Reg/Linear/X86_64.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/Data.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/ConLike.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/DataCon.hs-boot
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/PatSyn.hs
- compiler/GHC/Core/TyCo/Ppr.hs
- compiler/GHC/Core/TyCo/Rep.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e90b54c1bf248617b4f20b460dc21c5da9c5a34a...c2aeb0105565f916d0c7ad191a5a69540ffe1a71

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e90b54c1bf248617b4f20b460dc21c5da9c5a34a...c2aeb0105565f916d0c7ad191a5a69540ffe1a71
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/20200520/24816b77/attachment-0001.html>

More information about the ghc-commits mailing list