[Git][ghc/ghc][wip/exception-propagate] 21 commits: Add entity information to HieFile #24544

Rodrigo Mesquita (@alt-romes) gitlab at gitlab.haskell.org
Fri Sep 27 14:42:28 UTC 2024



Rodrigo Mesquita pushed to branch wip/exception-propagate at Glasgow Haskell Compiler / GHC


Commits:
1b39363b by Patrick at 2024-09-27T06:10:19-04:00
Add entity information to HieFile #24544

Enhanced HieFile to capture entity information for identifiers, enabling better support for language tools and protocols. See issue #24544 for more details.

Work have been done:
* Introduction of new data type `EntityInfo` in `GHC.Iface.Ext.Types`.
* Add extra field `hie_entity_infos :: NameEntityInfo` to `HieFile`
  to store the mapping from entity name to corresponding entity infos
  in `GHC.Iface.Ext.Types`.
* Compute `EntityInfo` for each entity name in the HieAst from `TyThing,
  Id, OccName` when generating the `HieFile` in `GHC.Iface.Ext.Ast`.
* Add test T24544 to test the generation of `EntityInfo`.

- - - - -
4f3618d8 by sheaf at 2024-09-27T06:10:57-04: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
-------------------------

- - - - -
10e431ef by sheaf at 2024-09-27T06:10:57-04: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

- - - - -
8238fb2d by sheaf at 2024-09-27T06:10:57-04: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.

- - - - -
2cb7b748 by sheaf at 2024-09-27T06:10:57-04: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.

- - - - -
0d2428d6 by sheaf at 2024-09-27T06:10:57-04: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.

- - - - -
e6c19a41 by sheaf at 2024-09-27T06:10:57-04: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.

- - - - -
f496ff7f by sheaf at 2024-09-27T06:10:57-04: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

- - - - -
5dd2a423 by sheaf at 2024-09-27T06:10:57-04:00
Add test for C calls & SIMD vectors

- - - - -
f824e1ee by sheaf at 2024-09-27T06:10:58-04:00
Add test for #25169

- - - - -
d54db7f3 by sheaf at 2024-09-27T06:10:58-04:00
Fix #25169 using Plan A from the ticket

We now compile certain low-level Cmm functions in the RTS multiple
times, with different levels of vector support. We then dispatch
at runtime in the RTS, based on what instructions are supported.

See Note [realArgRegsCover] in GHC.Cmm.CallConv.

Fixes #25169

-------------------------
Metric Increase:
    T10421
    T12425
    T18730
    T1969
    T9198
-------------------------

- - - - -
d5f8778a by sheaf at 2024-09-27T06:10:58-04:00
Fix C calls with SIMD vectors

This commit fixes the code generation for C calls, to take into account
the calling convention.

This is particularly tricky on Windows, where all vectors are expected
to be passed by reference. See Note [The Windows X64 C calling convention]
in GHC.CmmToAsm.X86.CodeGen.

- - - - -
f64bd564 by sheaf at 2024-09-27T06:10:58-04:00
X86 CodeGen: refactor getRegister CmmLit

This refactors the code dealing with loading literals into registers,
removing duplication and putting all the code in a single place.
It also changes which XOR instruction is used to place a zero value
into a register, so that we use VPXOR for a 128-bit integer vector
when AVX is supported.

- - - - -
ab12de6b by sheaf at 2024-09-27T06:10:58-04:00
X86 genCCall: promote arg before calling evalArgs

The job of evalArgs is to ensure each argument is put into a temporary
register, so that it can then be loaded directly into one of the
argument registers for the C call, without the generated code clobbering
any other register used for argument passing.

However, if we promote arguments after calling evalArgs, there is the
possibility that the code used for the promotion will clobber a register,
defeating the work of evalArgs.
To avoid this, we first promote arguments, and only then call evalArgs.

- - - - -
8fd12429 by sheaf at 2024-09-27T06:10:58-04:00
X86 genCCall64: simplify loadArg code

This commit simplifies the argument loading code by making the
assumption that it is safe to directly load the argument into register,
because doing so will not clobber any previous assignments.

This assumption is borne from the use of 'evalArgs', which evaluates
any arguments which might necessitate non-trivial code generation into
separate temporary registers.

- - - - -
12504a9f by sheaf at 2024-09-27T06:10:58-04:00
LLVM: propagate GlobalRegUse information

This commit ensures we keep track of how any particular global register
is being used in the LLVM backend. This informs the LLVM type
annotations, and avoids type mismatches of the following form:

  argument is not of expected type '<2 x double>'
    call ccc <2 x double> (<2 x double>)
      (<4 x i32> arg)

- - - - -
2bb1e8df by Cheng Shao at 2024-09-27T06:11:35-04:00
Link bytecode from interface-stored core bindings in oneshot mode

!13042

Part of #T25090

If the flag `-fprefer-byte-code` is given when compiling a module
containing TH, GHC will use Core bindings stored in interfaces to
compile and link bytecode for splices.

This was only implemented for `--make` mode initially, so this commit
adds the same mechanism to oneshot mode (`-c`).

When an interface is loaded into the EPS in `loadInterface` that has
dehydrated Core bindings, an entry is added to the new field
`eps_iface_bytecode`, containing an IO action that produces a bytecode
`Linkable`, lazily processing the `mi_extra_decls` by calling
`loadIfaceByteCode`.

When Template Haskell dependencies are resolved in `getLinkDeps`, this
action is looked up after loading a module's interface.
If it exists, the action is evaluated and the bytecode is added to the
set of `Linkable`s used for execution of the splice; otherwise it falls
back on the traditional object file.

Metric Decrease:
    MultiLayerModules
    T13701

- - - - -
7cb7172e by Matthew Pickering at 2024-09-27T06:12:12-04:00
ci: Fix variable inheritence for ghcup-metadata testing job

Downstream in ghcup-ci we use the CONFIGURE_ARGS variable to determine
how to setup all the different jobs.

On the downstream trigger this was being inherited from the default
setting in .gitlab.yml file.

Therefore this led to job failures as the necessary CONFIGURE_ARGS were
not being passed to the configure script when installing the bindist.

See docs:

* https://docs.gitlab.com/ee/ci/yaml/#inherit
* https://docs.gitlab.com/ee/ci/yaml/#triggerforward

1. inherit:variables:fals
  - This stops the global variables being inherited into the job and
    hence forwarded onto the downstream job.

2. trigger:forward:*
  - yaml_variables: true (default) pass yaml variables to downstream,
    this is important to pass the upstream pipeline id to downstream.
  - pipeline_variables: false (default) but don't pass pipeline
    variables (normal environment variables).

Fixes #25294

- - - - -
6df57436 by Matthew Pickering at 2024-09-27T15:42:18+01:00
Fix toException method for ExceptionWithContext

Fixes #25235

- - - - -
c351c148 by Matthew Pickering at 2024-09-27T15:42:18+01:00
Exception rethrowing

Basic changes:

* Change `catch` function to propagate exceptions using the
  WhileHandling mechanism.
* Introduce `catchNoPropagate`, which does the same as before, but
  passes an exception which can be rethrown.
* Introduce `rethrowIO` combinator, which rethrows an exception with a
  context and doesn't add a new backtrace.
* Introduce `tryWithContext` for a variant of `try` which can rethrow
  the exception with it's original context.
* onException is modified to rethrow the original error rather than
  creating a new callstack.
* Functions which rethrow in GHC.Internal.IO.Handle.FD,
  GHC.Internal.IO.Handle.Internals, GHC.Internal.IO.Handle.Text, and
  GHC.Internal.System.IO.Error are modified to not add a new callstack.

Implements CLC proposal#202 <https://github.com/haskell/core-libraries-committee/issues/202>

- - - - -
fa92c2f4 by Rodrigo Mesquita at 2024-09-27T15:42:18+01:00
Add test for #25300

This reverts commit f781b76635390b9f8c04362638193dc1b9c2541a.

- - - - -


30 changed files:

- .gitlab-ci.yml
- 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/Cmm/UniqueRenamer.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


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b23f019cf18224f937eacf3cde3e8deece4ec8eb...fa92c2f414dcfa6172e35efb75e4da649a2ebe7c

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b23f019cf18224f937eacf3cde3e8deece4ec8eb...fa92c2f414dcfa6172e35efb75e4da649a2ebe7c
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/20240927/64ebd73b/attachment-0001.html>


More information about the ghc-commits mailing list