Torsten Schmits authored 1 year ago and Marge Bot committed 1 year ago

Fixes #23272

Sylvain Henry authored 1 year ago and Marge Bot committed 1 year ago

- thread knowledge about levity into PrimRep instead of panicking
- JS: remove assumption that unlifted heap objects are rts objects (TVar#, etc.)

Doing this also fixes #22291 (test added).

There is a small performance hit (~1% more allocations).

Metric Increase:
    T18698a
    T18698b

Matthew Pickering authored 2 years ago and Marge Bot committed 1 year ago

Tracking ticket: #23059

This runs compile_and_run tests with optimised code with bytecode
interpreter

Changed submodules: hpc, process

Co-authored-by: Torsten Schmits <git@tryp.io>

Krzysztof Gogolewski authored 1 year ago and Marge Bot committed 1 year ago

The tests were originally skipped because ghci used not to support
unboxed tuples/sums.

sheaf authored 1 year ago and Marge Bot committed 1 year ago

This patch adds eight new primops that fuse a multiplication and an
addition or subtraction:

  - `{fmadd,fmsub,fnmadd,fnmsub}{Float,Double}#`

fmadd x y z is x * y + z, computed with a single rounding step.

This patch implements code generation for these primops in the following
backends:

  - X86, AArch64 and PowerPC NCG,
  - LLVM
  - C

WASM uses the C implementation. The primops are unsupported in the
JavaScript backend.

The following constant folding rules are also provided:

  - compute a * b + c when a, b, c are all literals,
  - x * y + 0 ==> x * y,
  - ±1 * y + z ==> z ± y and x * ±1 + z ==> z ± x.

NB: the constant folding rules incorrectly handle signed zero.
This is a known limitation with GHC's floating-point constant folding
rules (#21227), which we hope to resolve in the future.

Sylvain Henry authored 2 years ago and Marge Bot committed 1 year ago

Only when the divisor is definitely non-zero.

Sylvain Henry authored 2 years ago and Marge Bot committed 1 year ago

   (x / l1) / l2
   l1 and l2 /= 0
   l1*l2 doesn't overflow
   ==> x / (l1 * l2)

Sylvain Henry authored 2 years ago and Marge Bot committed 1 year ago

  case quotRemInt# x y of
     (# q, _ #) -> body
  ====>
   case quotInt# x y of
     q -> body

  case quotRemInt# x y of
     (# _, r #) -> body
  ====>
   case remInt# x y of
     r -> body

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

Previously UnliftedTVar2 would fail when run with multiple capabilities
(and possibly even with one capability) as it would assume that
`killThread#` would immediately kill the "increment" thread.

Also, refactor the the executable to now succeed with no output and
fails with an exit code.

Add JS backend adapted from the GHCJS project by Luite Stegeman.

Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.

Bump array submodule

Work funded by IOG.

Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

As noted in #21868, several primops accepting continuations producing
RuntimeRep-polymorphic results aren't nearly as polymorphic as their
types suggest. Document this limitation and adapt the `UnliftedWeakPtr`
test to avoid breaking this limitation in `keepAlive#`.

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

Ensuring that mulIntMayOflo# behaves as expected.

Krzysztof Gogolewski authored 3 years ago and Matthew Pickering committed 2 years ago

Users are supposed to import GHC.Exts rather than GHC.Prim.
Part of #18749.

sheaf authored 3 years ago and Marge Bot committed 3 years ago

  Don't instantiate type variables for :type in
  `GHC.Tc.Gen.App.tcInstFun`, to avoid inconsistently instantianting
  `r1` but not `r2` in the type

    forall {r1} (a :: TYPE r1) {r2} (b :: TYPE r2). ...

  This fixes #21088.

  This patch also changes the primop pretty-printer to ensure
  that we put all the inferred type variables first. For example,
  the type of reallyUnsafePtrEquality# is now

    forall {l :: Levity} {k :: Levity}
           (a :: TYPE (BoxedRep l))
           (b :: TYPE (BoxedRep k)).
      a -> b -> Int#

  This means we avoid running into issue #21088 entirely with
  the types of primops. Users can still write a type signature where
  the inferred type variables don't come first, however.

  This change to primops had a knock-on consequence, revealing that
  we were sometimes performing eta reduction on keepAlive#.
  This patch updates tryEtaReduce to avoid eta reducing functions
  with no binding, bringing it in line with tryEtaReducePrep,
  and thus fixing #21090.

sheaf authored 3 years ago and Marge Bot committed 3 years ago

This patch makes the following types levity-polymorphic in their
last argument:

  - Array# a, SmallArray# a, Weak# b, StablePtr# a, StableName# a

  - MutableArray# s a, SmallMutableArray# s a,
    MutVar# s a, TVar# s a, MVar# s a, IOPort# s a

The corresponding primops are also made levity-polymorphic, e.g.
`newArray#`, `readArray#`, `writeMutVar#`, `writeIOPort#`, etc.

Additionally, exception handling functions such as `catch#`, `raise#`,
`maskAsyncExceptions#`,... are made levity/representation-polymorphic.

Now that Array# and MutableArray# also work with unlifted types,
we can simply re-define ArrayArray# and MutableArrayArray# in terms
of them. This means that ArrayArray# and MutableArrayArray# are no
longer primitive types, but simply unlifted newtypes around Array# and
MutableArrayArray#.

This completes the implementation of the Pointer Rep proposal
  https://github.com/ghc-proposals/ghc-proposals/pull/203

Fixes #20911

-------------------------
Metric Increase:
    T12545
-------------------------

-------------------------
Metric Decrease:
    T12545
-------------------------

Sylvain Henry authored 3 years ago and Marge Bot committed 3 years ago

Primops types were dependent on the target word-size at *compiler*
compilation time. It's an issue for multi-target as GHC may not have the
correct primops types for the target.

This patch fixes some primops types: if they take or return fixed 64-bit
values they now always use `Int64#/Word64#`, even on 64-bit
architectures (where they used `Int#/Word#` before). Users of these
primops may now need to convert from Int64#/Word64# to Int#/Word# (a
no-op at runtime).

This is a stripped down version of !3658 which goes the all way of
changing the underlying primitive types of Word64/Int64. This is left
for future work.

T12545 allocations increase ~4% on some CI platforms and decrease ~3% on
AArch64.

Metric Increase:
    T12545

Metric Decrease:
    T12545

sheaf authored 3 years ago and Marge Bot committed 3 years ago

  This patch removes the following defaulting of type variables
  in type and data families:

    - type variables of kind RuntimeRep defaulting to LiftedRep
    - type variables of kind Levity defaulting to Lifted
    - type variables of kind Multiplicity defaulting to Many

  It does this by passing "defaulting options" to the `defaultTyVars`
  function; when calling from `tcTyFamInstEqnGuts` or
  `tcDataFamInstHeader` we pass options that avoid defaulting.

  This avoids wildcards being defaulted, which caused type families
  to unexpectedly fail to reduce.

  Note that kind defaulting, applicable only with -XNoPolyKinds,
  is not changed by this patch.

  Fixes #17536

-------------------------
Metric Increase:
    T12227
-------------------------

sheaf authored 3 years ago and Marge Bot committed 3 years ago

PHASE 1: we never rewrite Concrete# evidence.

This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form

  Concrete# :: forall k. k -> TupleRep '[]

Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.

This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).

fixes #17907 #20277 #20330 #20423 #20426

updates haddock submodule

-------------------------
Metric Decrease:
    T5642
-------------------------

Guillaume Bouchard authored 3 years ago and Marge Bot committed 3 years ago

The constraint was there in order to show the 'Integral' value in case
of error. Instead we can show the result of `toInteger`, which will be
close (i.e. it will still show the same integer except if the 'Show'
instance was funky).

This changes a bit runtime semantic (i.e. exception string may be a bit
different).

sheaf authored 3 years ago and Marge Bot committed 3 years ago

fixes #9192 and #17126
updates containers submodule

1. Changes the type of the primop `reallyUnsafePtrEquality#` to the most
general version possible (heterogeneous as well as levity-polymorphic):

> reallyUnsafePtrEquality#
>   :: forall {l :: Levity} {k :: Levity}
>        (a :: TYPE (BoxedRep l)) (b :: TYPE (BoxedRep k))
>   . a -> b -> Int#

2. Adds a new internal module, `GHC.Ext.PtrEq`, which contains pointer
equality operations that are now subsumed by `reallyUnsafePtrEquality#`.
These functions are then re-exported by `GHC.Exts` (so that no function
goes missing from the export list of `GHC.Exts`, which is user-facing).
More specifically, `GHC.Ext.PtrEq` defines:

  - A new function:
    * reallyUnsafePtrEquality :: forall (a :: Type). a -> a -> Int#

  - Library definitions of ex-primops:
     * `sameMutableArray#`
     * `sameSmallMutableArray`
     * `sameMutableByteArray#`
     * `sameMutableArrayArray#`
     * `sameMutVar#`
     * `sameTVar#`
     * `sameMVar#`
     * `sameIOPort#`
     * `eqStableName#`

  - New functions for comparing non-mutable arrays:
     * `sameArray#`
     * `sameSmallArray#`
     * `sameByteArray#`
     * `sameArrayArray#`

  These were requested in #9192.

Generally speaking, existing libraries that
use `reallyUnsafePtrEquality#` will continue to work with the new,
levity-polymorphic version. But not all!
Some (`containers`, `unordered-containers`, `dependent-map`) contain
the following:

> unsafeCoerce# reallyUnsafePtrEquality# a b

If we make `reallyUnsafePtrEquality#` levity-polymorphic, this code
fails the current GHC representation-polymorphism checks.
We agreed that the right solution here is to modify the library;
in this case by deleting the call to `unsafeCoerce#`,
since `reallyUnsafePtrEquality#` is now type-heterogeneous too.

Matthew Pickering authored 3 years ago and Marge Bot committed 3 years ago

This reverts commit d1f59540.

This commit breaks the build of unordered-containers

```
[3 of 9] Compiling Data.HashMap.Internal.Array ( Data/HashMap/Internal/Array.hs, dist/build/Data/HashMap/Internal/Array.o, dist/build/Data/HashMap/Internal/Array.dyn_o )
*** Parser [Data.HashMap.Internal.Array]:
Parser [Data.HashMap.Internal.Array]: alloc=21043544 time=13.621
*** Renamer/typechecker [Data.HashMap.Internal.Array]:
Renamer/typechecker [Data.HashMap.Internal.Array]: alloc=151218672 time=187.083
*** Desugar [Data.HashMap.Internal.Array]:
ghc: panic! (the 'impossible' happened)
  GHC version 9.3.20210625:
	expectJust splitFunTy
CallStack (from HasCallStack):
  error, called at compiler/GHC/Data/Maybe.hs:68:27 in ghc:GHC.Data.Maybe
  expectJust, called at compiler/GHC/Core/Type.hs:1247:14 in ghc:GHC.Core.Type
```

Revert containers submodule update

sheaf authored 3 years ago and Marge Bot committed 3 years ago

fixes #17126, updates containers submodule

Matthew Pickering authored 3 years ago and Marge Bot committed 3 years ago

Fixes #19851

Sylvain Henry authored 4 years ago and Marge Bot committed 4 years ago

The first change makes the array ones use the proper fixed-size types,
which also means that just like before, they can be used without
explicit conversions with the boxed sized types. (Before, it was Int# /
Word# on both sides, now it is fixed sized on both sides).

For the second change, don't use "extend" or "narrow" in some of the
user-facing primops names for conversions.

  - Names like `narrowInt32#` are misleading when `Int` is 32-bits.

  - Names like `extendInt64#` are flat-out wrong when `Int is
    32-bits.

  - `narrow{Int,Word}<N>#` however map a type to itself, and so don't
    suffer from this problem. They are left as-is.

These changes are batched together because Alex happend to use the array
ops. We can only use released versions of Alex at this time, sadly, and
I don't want to have to have a release thatwon't work for the final GHC
9.2. So by combining these we get all the changes for Alex done at once.

Bump hackage state in a few places, and also make that workflow slightly
easier for the future.

Bump minimum Alex version

Bump Cabal, array, bytestring, containers, text, and binary submodules

John Ericson authored 5 years ago and Marge Bot committed 4 years ago

Progress towards #19026.

The type was added before, but not its primops. We follow the
conventions in 36fcf9ed and
2c959a18 for names and testing.

Along with the previous 8- and 16-bit primops, this will allow us to
avoid many conversions for 8-, 16-, and 32-bit sized numeric types.

Co-authored-by: Sylvain Henry <hsyl20@gmail.com>

Sylvain Henry authored 4 years ago and Marge Bot committed 4 years ago

We must ensure that exceptions are not simplified. Previously we used:

   case raiseDivZero of
      _ -> 0## -- dummyValue

But it was wrong because the evaluation of `raiseDivZero` was removed and
the dummy value was directly returned. See new Note [ghc-bignum exceptions].

I've also removed the exception triggering primops which were fragile.
We don't need them to be primops, we can have them exported by ghc-prim.

I've also added a test for #18359 which triggered this patch.

Andrew Martin authored 5 years ago and Marge Bot committed 4 years ago

This function and its accompanying rule resolve issue #5218.
A future PR to the bytestring library will make the internal
Data.ByteString.Internal.unsafePackAddress compute string length
with cstringLength#. This will improve the status quo because it is
eligible for constant folding.

Additionally, introduce a new data constructor to ForeignPtrContents
named FinalPtr. This additional data constructor, when used in the
IsString instance for ByteString, leads to more Core-to-Core
optimization opportunities, fewer runtime allocations, and smaller
binaries.

Also, this commit re-exports all the functions from GHC.CString
(including cstringLength#) in GHC.Exts. It also adds a new test
driver. This test driver is used to perform substring matches on Core
that is dumped after all the simplifier passes. In this commit, it is
used to check that constant folding of cstringLength# works.

Andrew Martin authored 5 years ago and Marge Bot committed 5 years ago

This is a part of GHC Proposal #25: "Offer more array resizing primitives".
Resources related to the proposal:

  - Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/121
  - Proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0025-resize-boxed.rst

Only shrinkSmallMutableArray# is implemented as a primop since a
library-space implementation of resizeSmallMutableArray# (in GHC.Exts)
is no less efficient than a primop would be. This may be replaced by
a primop in the future if someone devises a strategy for growing
arrays in-place. The library-space implementation always copies the
array when growing it.

This commit also tweaks the documentation of the deprecated
sizeofMutableByteArray#, removing the mention of concurrency. That
primop is unsound even in single-threaded applications. Additionally,
the non-negativity assertion on the existing shrinkMutableByteArray#
primop has been removed since this predicate is trivially always true.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

Previously there were a few cases where operations like `omit_ways`
were incorrectly passed a single way (e.g. `omit_ways('threaded2')`).
This won't work as the author expected.

Ömer Sinan Ağacan authored 5 years ago and Marge Bot committed 5 years ago

These tests use unboxed tuples, which GHCi doesn't support