[Git][ghc/ghc][wip/llvm-version-bsd] 14 commits: ttg: Use List instead of Bag in AST for LHsBindsLR

Matthew Pickering (@mpickering) gitlab at gitlab.haskell.org
Mon Jun 24 14:51:48 UTC 2024 


Matthew Pickering pushed to branch wip/llvm-version-bsd at Glasgow Haskell Compiler / GHC


Commits:
24e89c40 by Jacco Krijnen at 2024-06-20T07:21:27-04:00
ttg: Use List instead of Bag in AST for LHsBindsLR

Considering that the parser used to create a Bag of binds using a
cons-based approach, it can be also done using lists. The operations in
the compiler don't really require Bag.

By using lists, there is no dependency on GHC.Data.Bag anymore from the
AST.

Progress towards #21592

- - - - -
04f5bb85 by Simon Peyton Jones at 2024-06-20T07:22:03-04:00
Fix untouchability test

This MR fixes #24938.  The underlying problem was tha the test for
"does this implication bring in scope any equalities" was plain wrong.

See
  Note [Tracking Given equalities] and
  Note [Let-bound skolems]
both in GHC.Tc.Solver.InertSet.

Then
* Test LocalGivenEqs succeeds for a different reason than before;
  see (LBS2) in Note [Let-bound skolems]

* New test T24938a succeeds because of (LBS2), whereas it failed
  before.

* Test LocalGivenEqs2 now fails, as it should.

* Test T224938, the repro from the ticket, fails, as it should.

- - - - -
9a757a27 by Simon Peyton Jones at 2024-06-20T07:22:40-04:00
Fix demand signatures for join points

This MR tackles #24623 and #23113

The main change is to give a clearer notion of "worker/wrapper arity", esp
for join points. See GHC.Core.Opt.DmdAnal
     Note [Worker/wrapper arity and join points]
This Note is a good summary of what this MR does:

(1) The "worker/wrapper arity" of an Id is
    * For non-join-points: idArity
    * The join points: the join arity (Id part only of course)
    This is the number of args we will use in worker/wrapper.
    See `ww_arity` in `dmdAnalRhsSig`, and the function `workWrapArity`.

(2) A join point's demand-signature arity may exceed the Id's worker/wrapper
    arity.  See the `arity_ok` assertion in `mkWwBodies`.

(3) In `finaliseArgBoxities`, do trimBoxity on any argument demands beyond
    the worker/wrapper arity.

(4) In WorkWrap.splitFun, make sure we split based on the worker/wrapper
    arity (re)-computed by workWrapArity.

- - - - -
5e8faaf1 by Jan Hrček at 2024-06-20T07:23:20-04:00
Update haddocks of Import/Export AST types

- - - - -
cd512234 by Hécate Kleidukos at 2024-06-20T07:24:02-04:00
haddock: Update bounds in cabal files and remove allow-newer stanza in cabal.project

- - - - -
8a8ff8f2 by Rodrigo Mesquita at 2024-06-20T07:24:38-04:00
cmm: Don't parse MO_BSwap for W8

Don't support parsing bswap8, since bswap8 is not really an operation
and would have to be implemented as a no-op (and currently is not
implemented at all).

Fixes #25002

- - - - -
5cc472f5 by sheaf at 2024-06-20T07:25:14-04:00
Delete unused testsuite files

These files were committed by mistake in !11902.
This commit simply removes them.

- - - - -
7b079378 by Matthew Pickering at 2024-06-20T07:25:50-04:00
Remove left over debugging pragma from 2016

This pragma was accidentally introduced in 648fd73a7b8fbb7955edc83330e2910428e76147

The top-level cost centres lead to a lack of optimisation when compiling
with profiling.

- - - - -
c872e09b by Hécate Kleidukos at 2024-06-20T19:28:36-04:00
haddock: Remove unused pragmata, qualify usages of Data.List functions, add more sanity checking flags by default

This commit enables some extensions and GHC flags in the cabal file in a way
that allows us to reduce the amount of prologuing on top of each file.

We also prefix the usage of some List functions that removes ambiguity
when they are also exported from the Prelude, like foldl'.
In general, this has the effect of pointing out more explicitly
that a linked list is used.

Metric Increase:
    haddock.Cabal
    haddock.base
    haddock.compiler

- - - - -
8c87d4e1 by Arnaud Spiwack at 2024-06-20T19:29:12-04:00
Add test case for #23586

- - - - -
568de8a5 by Arnaud Spiwack at 2024-06-20T19:29:12-04:00
When matching functions in rewrite rules: ignore multiplicity

When matching a template variable to an expression, we check that it
has the same type as the matched expression. But if the variable `f` has
type `A -> B` while the expression `e` has type `A %1 -> B`, the match was
previously rejected.

A principled solution would have `f` substituted by `\(%Many x) -> e
x` or some other appropriate coercion. But since linearity is not
properly checked in Core, we can be cheeky and simply ignore
multiplicity while matching. Much easier.

This has forced a change in the linter which, when `-dlinear-core-lint`
is off, must consider that `a -> b` and `a %1 -> b` are equal. This is
achieved by adding an argument to configure the behaviour of
`nonDetCmpTypeX` and modify `ensureEqTys` to call to the new behaviour
which ignores multiplicities when comparing two `FunTy`.

Fixes #24725.

- - - - -
c8a8727e by Simon Peyton Jones at 2024-06-20T19:29:12-04:00
Faster type equality

This MR speeds up type equality, triggered by perf regressions that
showed up when fixing #24725 by parameterising type equality over
whether to ignore multiplicity.

The changes are:

* Do not use `nonDetCmpType` for type /equality/. Instead use a specialised
  type-equality function, which we have always had!

  `nonDetCmpType` remains, but I did not invest effort in refactoring
  or optimising it.

* Type equality is parameterised by
    - whether to expand synonyms
    - whether to respect multiplicities
    - whether it has a RnEnv2 environment
  In this MR I systematically specialise it for static values of these
  parameters.  Much more direct and predictable than before.  See
  Note [Specialising type equality]

* We want to avoid comparing kinds if possible.  I refactored how this
  happens, at least for `eqType`.
  See Note [Casts and coercions in type comparison]

* To make Lint fast, we want to avoid allocating a thunk for <msg> in
      ensureEqTypes ty1 ty2 <msg>
  because the test almost always succeeds, and <msg> isn't needed.
  See Note [INLINE ensureEqTys]

Metric Decrease:
    T13386
    T5030

- - - - -
7b240137 by Matthew Pickering at 2024-06-24T15:48:06+01:00
Expand LLVM version matching regex for compability with bsd systems

sed on BSD systems (such as darwin) does not support the + operation.

Therefore we take the simple minded approach of manually expanding
group+ to groupgroup*.

Fixes #24999

- - - - -
a82ec650 by Matthew Pickering at 2024-06-24T15:50:10+01:00
ci: On darwin configure LLVMAS linker to match LLC and OPT toolchain

The version check was previously broken so the toolchain was not
detected at all.

- - - - -


30 changed files:

- .gitlab/darwin/toolchain.nix
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Multiplicity.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/WorkWrap.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/TyCo/Compare.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/ImpExp.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Stats.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Pmc/Desugar.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Parser/PostProcess/Haddock.hs
- compiler/GHC/Rename/Bind.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8ac2001b6240d4f039cb807b4fff6cbd8324a457...a82ec650352214bffcffc6f6edd967ab4c310f70

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8ac2001b6240d4f039cb807b4fff6cbd8324a457...a82ec650352214bffcffc6f6edd967ab4c310f70
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/20240624/8d1ea0d0/attachment-0001.html>

More information about the ghc-commits mailing list