Select Git revision
Search by author
- Any Author
- authors
-
Aaron Allen aaronallen8455
-
absolutely proprietary absolutelyproprietary
-
adam adamse
-
Adam Gundry adamgundry
-
Adam Wespiser
adamwespiser
-
Aditya Manthramurthy donatello
-
Administrator root
-
Adriaan Leijnse aidylns
-
Alan Zimmerman alanz
-
Alec Theriault harpocrates
-
Alejandro Serrano Mena trupill
-
Aleksei Vagarenko vagarenko
-
Alexander Foremny aforemny
-
Alexander Gugel alexanderGugel
-
Alexander Kjeldaas alexanderkjeldaas
-
Alexander Vershilov qnikst
-
Alexandre Garcia de Oliveira romefeller
-
Alexandre R. Baldé
rockbmb
-
Alex Biehl alexbiehl
-
Alex D
nineonine
- Sep 27, 2024
-
-
Zubin authored
-
Zubin authored
-
-
Add support for wildcard binders in type declarations: type Const a b = a -- BEFORE: the `b` had to be named -- even if unused on the RHS type Const a _ = a -- AFTER: the compiler accepts -- a wildcard binder `_` The new feature is part of GHC Proposal #425 "Invisible binders in type declarations", and more specifically its amendment #641. Just like a named binder, a wildcard binder `_` may be: * plain: _ * kinded: (_ :: k -> Type) * invisible, plain: @_ * invisible, kinded: @(_ :: k -> Type) Those new forms of binders are allowed to occur on the LHSs of data, newtype, type, class, and type/data family declarations: data D _ = ... newtype N _ = ... type T _ = ... class C _ where ... type family F _ data family DF _ (Test case: testsuite/tests/typecheck/should_compile/T23501a.hs) However, we choose to reject them in forall telescopes and type family result variable binders (the latter being part of the TypeFamilyDependencies extension): type family Fd a = _ -- disallowed (WildcardBndrInTyFamResultVar) fn :: forall _. Int -- disallowed (WildcardBndrInForallTelescope) (Test case: testsuite/tests/rename/should_fail/T23501_fail.hs) See the new Notes: * Note [Type variable binders] * Note [Wildcard binders in disallowed contexts] To accommodate the new forms of binders, HsTyVarBndr was changed as follows (demonstrated without x-fields for clarity) -- BEFORE (ignoring x-fields and locations) data HsTyVarBndr flag = UserTyVar flag Name | KindedTyVar flag Name HsKind -- AFTER (ignoring x-fields and locations) data HsTyVarBndr flag = HsTvb flag HsBndrVar HsBndrKind data HsBndrVar = HsBndrVar Name | HsBndrWildCard data HsBndrKind = HsBndrNoKind | HsBndrKind LHsKind The rest of the patch is downstream from this change. To avoid a breaking change to the TH AST, we generate fresh names to replace wildcard binders instead of adding a dedicated representation for them (as discussed in #641). And to put a cherry on top of the cake, we now allow wildcards in kind-polymorphic type variable binders in constructor patterns, see Note [Type patterns: binders and unifiers] and the tyPatToBndr function in GHC.Tc.Gen.HsType; example: fn (MkT @(_ :: forall k. k -> Type) _ _) = ... (Test case: testsuite/tests/typecheck/should_compile/T23501b.hs)
-
-
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
-
!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
-
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) -
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.
-
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.
-
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.
-
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.
-
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 -------------------------
-
-
-
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
-
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.
-
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.
-
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.
-
-
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
-
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 ------------------------- -
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`.
-
- Sep 26, 2024
-
-
This patch just removes all the functions related to wiring-in the base package and the `-this-unit-id=base` flag from the cabal file. After this commit "base" becomes just like any other package and the door is opened to moving base into an external repo and releasing base on a separate schedule to the rest of ghc. Closes #24903
-
-
There is currently a warning implemented in -Wcompat which warns you when importing Data.List in a non-qualified manner. ``` A.hs:3:8: warning: [-Wcompat-unqualified-imports] To ensure compatibility with future core libraries changes imports to Data.List should be either qualified or have an explicit import list. | 3 | import Data.List | ^^^^^^^^^ Ok, one module loaded. ``` GHC ticket: #17244 CLC discussion: https://groups.google.com/g/haskell-core-libraries/c/q3zHLmzBa5E This warning was implemented as part of the migration to making Data.List monomorphic again (and to be used like Data.Set, Data.Map etc). That doesn't seem like it happened, and I imagine that the current CLC would require a new proposal anyway in order to do that now. It's not clear in any case what "future core libraries changes" we are waiting to happen before this warning can be removed. Given the first phase of the proposal has lasted 5 years it doesn't seem that anyone is motivated to carry the proposal to completion. It does seem a bit unnecessary to include a warning in the compiler about "future changes to the module" when there's no timeline or volunteer to implement these changes. The removal of this warning was discussed again at: https://github.com/haskell/core-libraries-committee/issues/269 During the discussion there was no new enthusiasm to move onto the next stages of the proposal so we are removing the warning to unblock the reinstallable "base" project (#24903) Fixes #24904 -
This occurence of baseUnitId was missed when moving the bulk of internal definitions into `ghc-internal`. We need to remove this preloading of `base` now because `base` should not be wired in. Towards #24903
-
The COMPILING_BASE_PACKAGE macro is concerned with issues defining symbols and using symbols in the same compilation unit. However, these symbols now exist in ghc-internal rather than base, so we should rename the macro accordingly. The code is guards is likely never used as we never produce windows DLLs but it is simpler to just perform the renaming for now. These days there is little doubt that this macro defined in this ad-hoc manner would be permitted to exist, but these days are not those days. Fixes #25221
-
This behaviour is problematic for the principle reason that `import Prelude` may not refer to the `base` package, and in which case importing an entirely unrelated module causing your implicit prelude to leave the scope is extremely surprising. See the added test for this example. Discussion on #17045. The secondary reason for reverting this patch is that "base" can't be a wired in package any more (see #24903), so we have to remove special logic which singles out base from the compiler. The rule for implicit shadowing is now simply: * If you write import Prelude (..) then you don't get an implicit prelude import * If you write import "foobar" Prelude (..) for all pkgs foobar, you get an implicit import of prelude. If you want to write a package import of Prelude, then you can enable `NoImplicitPrelude` for the module in question to recover the behaviour of ghc-9.2-9.10. Fixes #17045
-
Metric Increase: MultilineStringsPerf This commit replaces the manual string lexing logic with native Alex lexing syntax. This aligns the lexer much closer to the Haskell Report, making it easier to see how the implementation and spec relate. This slightly increases memory usage when compiling multiline strings because we now have two distinct phases: lexing the multiline string with Alex and post-processing the string afterwards. Before, these were done at the same time, but separating them allows us to push as much logic into normal Alex lexing as possible. Since multiline strings are a new feature, this regression shouldn't be too noticeable. We can optimize this over time. -
This enables late cost centres when building profiled libraries and subsequently greatly improves the resolution of cost centre stacks when profiling. This patch also introduces the `grep_prof` test modifier which is used to apply a further filter to the .prof file before they are compared. Fixes #21732 ------------------------- Metric Increase: libdir -------------------------
-
These normalisation steps were collapsing lines together, which made subsequent normalisation steps fail. ``` foo x y z CAF x y z qux x y z ``` was getting normalised to ``` foo x y z qux x y z ``` which means that subsequent line based filters would not work correctly.
-
Fix 1: If a cost centre contained CAF then the normalisation was corrupted, now only check if CAF is at the start of a line. Fix 2: "no location info" contain a space, which messed up the next normalisation logic which assumed that columns didn't have spaced in.
-
The `asBox` function is intended to store exactly the closure which the user passes to it. Placing a cost centre on asBox introduces a thunk, which violates this expectation and can change the result of using asBox when profiling is enabled. See #25212 for more details and ample opportunity to discuss if this is a bug or not.
-
Rules: x or (x and y) ==> x x and (x or y) ==> x
-
Generate better code for Enum.toEnum: check both the lower and the upper bounds at once with an unsigned comparison. Initially I've used a type ascription with a call to 'fromIntegral', hence the slight refactoring of nlAscribe. Using 'fromIntegral' was problematic (too low in the module hierarchy) so 'enumIntToWord' was introduced instead. Combined with the previous commit, T21839c ghc/alloc decrease by 5% Metric Decrease: T21839c -
Reuse predError, succError, and toEnumError when deriving Enum instances to avoid generating different error strings per instance. E.g. before this patch for every instance for a type FOO we would generate a string: "pred{FOO}: tried to take `pred' of first tag in enumeration"# -
-working-dir definitely needs more serious testing, there are some easy ways to test this. * Modify Cabal to call ghc using -working-dir rather than changing directory. * Modify the testsuite to run ghc using `-working-dir` rather than running GHC with cwd = temporary directory. However this will have to wait until after 9.12. Fixes #25150
-
Previously `errorCallWithCallStackException` failed to propagate its `CallStack` argument, which represents the call-chain of the preceding `error` call, to the exception that it returned. Consequently, the call-stack of `error` calls were quite useless. Unfortunately, this is the second time that I have fixed this but it seems the first must have been lost in rebasing. Fixes a bug in the implementation of CLC proposal 164 <https://github.com/haskell/core-libraries-committee/issues/164> Fixes #24807.
-
- Sep 25, 2024
-
-
strlen returns the length of the string without the \0 terminating byte, hence CString weren't properly allocated on the heap (ending \0 byte was missing).
-
