[Git][ghc/ghc][wip/ncg-simd] 14 commits: Print exception metadata in default handler

sheaf (@sheaf) gitlab at gitlab.haskell.org
Tue Aug 6 11:27:46 UTC 2024 


sheaf pushed to branch wip/ncg-simd at Glasgow Haskell Compiler / GHC


Commits:
ff158fcd by Tommy Bidne at 2024-08-02T01:14:32+12:00
Print exception metadata in default handler

CLC proposals 231 and 261:

- Add exception type metadata to SomeException's displayException.
- Add "Exception" header to default exception handler.

See:

https://github.com/haskell/core-libraries-committee/issues/231
https://github.com/haskell/core-libraries-committee/issues/261

Update stm submodule for test fixes.

- - - - -
8b2f70a2 by Andrei Borzenkov at 2024-08-01T23:00:46-04:00
Type syntax in expressions (#24159, #24572, #24226)

This patch extends the grammar of expressions with syntax that is
typically found only in types:
  * function types (a -> b), (a ->. b), (a %m -> b)
  * constrained types (ctx => t)
  * forall-quantification (forall tvs. t)

The new forms are guarded behind the RequiredTypeArguments extension,
as specified in GHC Proposal #281. Examples:

  {-# LANGUAGE RequiredTypeArguments #-}
  e1 = f (Int    -> String)          -- function type
  e2 = f (Int %1 -> String)          -- linear function type
  e3 = f (forall a. Bounded a => a)  -- forall type, constraint

The GHC AST and the TH AST have been extended as follows:

   syntax        | HsExpr   | TH.Exp
  ---------------+----------+--------------
   a -> b        | HsFunArr | ConE (->)
   a %m -> b     | HsFunArr | ConE FUN
   ctx => t      | HsQual   | ConstrainedE
   forall a. t   | HsForAll | ForallE
   forall a -> t | HsForAll | ForallVisE

Additionally, a new warning flag -Wview-pattern-signatures has been
introduced to aid with migration to the new precedence of (e -> p :: t).

Co-authored-by: Vladislav Zavialov <vlad.z.4096 at gmail.com>

- - - - -
66e7f57d by Brandon Chinn at 2024-08-01T21:50:58-07:00
Implement MultilineStrings (#24390)

This commit adds support for multiline strings, proposed at
https://github.com/ghc-proposals/ghc-proposals/pull/569.
Multiline strings can now be written as:

    myString =
      """
      this is a
      multiline string
      """

The multiline string will have leading indentation stripped away.
Full details of this post-processing may be found at the new
GHC.Parser.String module.

In order to cleanly implement this and maximize reusability, I
broke out the lexing logic for strings out of Lexer.x into a
new GHC.Parser.String module, which lexes strings with any
provided "get next character" function. This also gave us the
opportunity to clean up this logic, and even optimize it a bit.
With this change, parsing string literals now takes 25% less
time and 25% less space.

- - - - -
cf47b96f by Rodrigo Mesquita at 2024-08-03T05:59:40-04:00
hi: Stable sort avails

Sorting the Avails in DocStructures is required to produce fully
deterministic interface files in presence of re-exported modules.

Fixes #25104

- - - - -
af2ae742 by M. Taimoor Zaeem at 2024-08-03T18:52:50+05:00
haddock: decrease margin on top of small headings

- - - - -
a1e42e7a by Rodrigo Mesquita at 2024-08-05T21:03:04-04:00
hi: Deterministic ImportedMods in Usages

The `mi_usages` field of the interface files must use a deterministic
list of `Usage`s to guarantee a deterministic interface. However, this
list was, in its origins, constructed from a `ModuleEnv` which uses a
non-deterministic ordering that was leaking into the interface.

Specifically, ImportedMods = ModuleEnv ... would get converted to a list and
then passed to `mkUsageInfo` to construct the Usages.

The solution is simple. Back `ImportedMods` with a deterministic map.
`Map Module ...` is enough, since the Ord instance for `Module` already
uses a stable, deterministic, comparison.

Fixes #25131

- - - - -
6020742d by sheaf at 2024-08-06T13:27:17+02:00
The X86 SIMD patch.

This commit adds support for 128 bit wide SIMD vectors and vector
operations to GHC's X86 native code generator.

Main changes:

  - Introduction of vector formats (`GHC.CmmToAsm.Format`)
  - Introduction of 128-bit virtual register (`GHC.Platform.Reg`),
    and removal of unused Float virtual register.
  - Refactor of `GHC.Platform.Reg.Class.RegClass`: it now only contains
    two classes, `RcInteger` (for general purpose registers) and `RcFloatOrVector`
    (for registers that can be used for scalar floating point values as well
    as vectors).
  - Modify `GHC.CmmToAsm.X86.Instr.regUsageOfInstr` to keep track
    of which format each register is used at, so that the register
    allocator can know if it needs to spill the entire vector register
    or just the lower 64 bits.
  - Modify spill/load/reg-2-reg code to account for vector registers
    (`GHC.CmmToAsm.X86.Instr.{mkSpillInstr, mkLoadInstr, mkRegRegMoveInstr, takeRegRegMoveInstr}`).
  - Modify the register allocator code (`GHC.CmmToAsm.Reg.*`) to propagate
    the format we are storing in any given register, for instance changing
    `Reg` to `RegFormat` or `GlobalReg` to `GlobalRegUse`.
  - Add logic to lower vector `MachOp`s to X86 assembly
    (see `GHC.CmmToAsm.X86.CodeGen`)
  - Minor cleanups to genprimopcode, to remove the llvm_only attribute
    which is no longer applicable.

Tests for this feature are provided in the "testsuite/tests/simd" directory.

Fixes #7741

Keeping track of register formats adds a small memory overhead to the
register allocator (in particular, regUsageOfInstr now allocates more
to keep track of the `Format` each register is used at). This explains
the following metric increases.

-------------------------
Metric Increase:
    T12707
    T13035
    T13379
    T3294
    T4801
    T5321FD
    T5321Fun
    T783
-------------------------

- - - - -
444ba1b6 by sheaf at 2024-08-06T13:27:17+02:00
Use xmm registers in genapply

This commit updates genapply to use xmm, ymm and zmm registers, for
stg_ap_v16/stg_ap_v32/stg_ap_v64, respectively.

It also updates the Cmm lexer and parser to produce Cmm vectors rather
than 128/256/512 bit wide scalars for V16/V32/V64, removing bits128,
bits256 and bits512 in favour of vectors.

The Cmm Lint check is weakened for vectors, as (in practice, e.g. on X86)
it is okay to use a single vector register to hold multiple different
types of data, and we don't know just from seeing e.g. "XMM1" how to
interpret the 128 bits of data within.

Fixes #25062

- - - - -
288d1147 by sheaf at 2024-08-06T13:27:17+02:00
Add vector fused multiply-add operations

This commit adds fused multiply add operations such as `fmaddDoubleX2#`.
These are handled both in the X86 NCG and the LLVM backends.

- - - - -
b96ec274 by sheaf at 2024-08-06T13:27:17+02:00
Add vector shuffle primops

This adds vector shuffle primops, such as

```
shuffleFloatX4# :: FloatX4# -> FloatX4# -> (# Int#, Int#, Int#, Int# #) -> FloatX4#
```

which shuffle the components of the input two vectors into the output vector.

NB: the indices must be compile time literals, to match the X86 SHUFPD
instruction immediate and the LLVM shufflevector instruction.

These are handled in the X86 NCG and the LLVM backend.

Tested in simd009.

- - - - -
ca470f50 by sheaf at 2024-08-06T13:27:18+02:00
Add Broadcast MachOps

This adds proper MachOps for broadcast instructions, allowing us to
produce better code for broadcasting a value than simply packing that
value (doing many vector insertions in a row).

These are lowered in the X86 NCG and LLVM backends. In the LLVM backend,
it uses the previously introduced shuffle instructions.

- - - - -
16caa0b2 by sheaf at 2024-08-06T13:27:18+02:00
Fix treatment of signed zero in vector negation

This commit fixes the handling of signed zero in floating-point vector
negation.

A slight hack was introduced to work around the fact that Cmm doesn't
currently have a notion of signed floating point literals
(see get_float_broadcast_value_reg). This can be removed once CmmFloat
can express the value -0.0.

The simd006 test has been updated to use a stricter notion of equality
of floating-point values, which ensure the validity of this change.

- - - - -
d3dd923a by sheaf at 2024-08-06T13:27:18+02:00
Add min/max primops

This commit adds min/max primops, such as

  minDouble# :: Double# -> Double# -> Double#
  minFloatX4# :: FloatX4# -> FloatX4# -> FloatX4#
  minWord16X8# :: Word16X8# -> Word16X8# -> Word16X8#

These are supported in:
  - the X86, AArch64 and PowerPC NCGs,
  - the LLVM backend,
  - the WebAssembly and JavaScript backends.

Fixes #25120

- - - - -
55da517a by sheaf at 2024-08-06T13:27:19+02:00
Modularise RegClass

This commit modularises the RegClass datatype, allowing it to be
used with architectures that have different register architectures, e.g.
RISC-V which has separate floating-point and vector registers.

The two modules GHC.Platform.Reg.Class.Unified and
GHC.Platform.Reg.Class.Separate implement the two register architectures
we currently support (corresponding to the two constructors of the
GHC.Platform.Reg.Class.RegArch datatype).

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Cmm/Graph.hs
- compiler/GHC/Cmm/Lexer.x
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/Liveness.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Opt.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ProcPoint.hs
- compiler/GHC/Cmm/Reg.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Type.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/AArch64/Regs.hs
- compiler/GHC/CmmToAsm/Config.hs
- compiler/GHC/CmmToAsm/Format.hs
- compiler/GHC/CmmToAsm/Instr.hs
- compiler/GHC/CmmToAsm/PPC.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/Instr.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3aec009b6f34d80318e2f25739f9efe19c028ae8...55da517aa6ab3e88e53d31d2f13355212b06c2b5

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3aec009b6f34d80318e2f25739f9efe19c028ae8...55da517aa6ab3e88e53d31d2f13355212b06c2b5
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/20240806/695fa755/attachment-0001.html>

More information about the ghc-commits mailing list