Commits on Source (98)
-
34d08a20
-
c5deaa27
-
In #20740 I noticed that mkUniqSet does not fuse. In practice, allowing it to do so makes a considerable difference in allocations due to the backend. Metric Decrease: T12707 T13379 T3294 T4801 T5321FD T5321Fun T783
b947250b -
6c88c2ba
-
It's useful to see which value made the pattern match fail. (If it ever occurs.)
5f1154e0 -
This case wasn't handled before. But, the test-primops test suite showed that it actually might appear.
e8c9a95f -
The test expects a perfect implementation with no false positives.
a36f9dc9 -
We also now save the jobs-metadata.json and jobs.yaml file as artifacts as: * It might be useful for someone who is modifying CI to copy jobs.yaml if they are having trouble regenerating locally. * jobs-metadata.json is very useful for downstream pipelines to work out the right job to download. Fixes #23654
38a36248 -
Create new release notes for the next GHC release (GHC 9.10)
1535a671 -
When we look up children GlobalRdrElts of a given Parent, we sometimes would rather prioritise those GlobalRdrElts which have the right Parent, and sometimes prioritise those that have the right NameSpace: - in export lists, we should prioritise NameSpace - for class/instance binders, we should prioritise Parent See Note [childGREPriority] in GHC.Types.Name.Reader. fixes #23664
3bd4d5b5 -
Ensure the LHsDecl for a FunBind has the correct leading comments and trailing annotations. See the added note for details.
9c8fdda3 -
Matthew Pickering authored
These were left over after 6078b429
ff884b77 -
Matthew Pickering authored
This allows you to load `gen_ci.hs` into HLS, and now it is a huge module, that is quite useful.
29ef590c -
Matthew Pickering authored
We are trying out a lighter weight validation pipeline where by default we just test on 5 platforms: * x86_64-deb10-slow-validate * windows * x86_64-fedora33-release * aarch64-darwin * aarch64-linux-deb10 In order to enable the "full" validation pipeline you can apply the `full-ci` label which will enable all the validation pipelines. All the validation jobs are still run on a marge batch. The goal is to reduce the overall CI capacity so that pipelines start faster for MRs and marge bot batches are faster. Fixes #23694
808b55cf -
This is the next patch in a series simplifying location management in GHC/Parser.y This one simplifies sL1, to use the HasLoc instances introduced in !10743 (closed)
0b23db03 -
The binutils documentation (for COFF) claims, > If no flags are specified, the default flags depend upon the section > name. If the section name is not recognized, the default will be for the > section to be loaded and writable. We previously assumed that this would do the right thing for split sections (e.g. a section named `.text$foo` would be correctly inferred to be a text section). However, we have observed that this is not the case (at least under the clang toolchain used on Windows): when split-sections is enabled, text sections are treated by the assembler as data (matching the "default" behavior specified by the documentation). Avoid this by setting section flags explicitly. This should fix split sections on Windows. Fixes #22834.
3ece9856 -
db7f7240
-
Causes haddock comments in signature modules to be properly inserted into the AST (just as they are for regular modules) if the `-haddock` flag is given. Also adds a test that compares `-ddump-parsed-ast` output for a signature module to prevent further regressions. Fixes #23315
b444c16f -
This addresses an odd asymmetry in the ByteArray# primops, which previously provided unsafeFreezeByteArray# but no corresponding thaw operation. Closes #22710
c30cea53 -
This discussion didn't make it into the original MR.
87f9bd47 -
We now supply the non-essential options to haddock using the `extraArgs` field, which can be specified in a Flavour so that if an advanced user wants to change how documentation is generated then they can use something other than the `defaultHaddockExtraArgs`. This does have the potential to regress some packaging if a user has overridden `extraArgs` themselves, because now they also need to add the haddock options to extraArgs. This can easily be done by appending `defaultHaddockExtraArgs` to their extraArgs invocation but someone might not notice this behaviour has changed. In any case, I think passing the non-essential options in this manner is the right thing to do and matches what we do for the "ghc" builder, which by default doesn't pass any optmisation levels, and would likewise be very bad if someone didn't pass suitable `-O` levels for builds. Fixes #23625
e4350b41 -
Commit b4d39adb made 'hs_cmpxchg64()' available to all architectures. Unfortunately this made GHC to fail to build on armel, since armel needs libatomic to support atomic operations on 64-bit word sizes. Configure libraries/ghc-prim/ghc-prim.cabal to link against libatomic, the same way as we do in rts/rts.cabal.
fc186b0c -
-
It was fixed by commit e1590ddc: Add the SolverStage monad.
5ad8d597 -
-
In !10907 I made the majority of jobs not run on a validate pipeline but then forgot to renable a select few jobs on the marge batch MR.
4876fddc -
packaging.version seems able to handle this fine
026991d7 -
We mention that if you need a full validation pipeline then you can apply the ~full-ci label to your MR in order to test against the full validation pipeline (like we do for marge).
b91bbc2b -
Commit 08ba8720 failed to declare the dependency of keepCAFsForGHCi on the symbol setKeepCAFs in the RTS, which led to undefined symbol errors on Windows, as exhibited by the testcase frontend001. Thanks to Moritz Angermann and Ryan Scott for the diagnosis and fix. Fixes #22961
42b05e9b -
-
-
- Remove unused RDR names - Fix typos in comments - Deriving: simplify boxConTbl and remove unused litConTbl - chmod -x GHC/Exts.hs, this seems accidental
a7349217 -
This patch implements part 1 of GHC Proposal #281, introducing explicit `type` patterns and `type` arguments. Summary of the changes: 1. New extension flag: RequiredTypeArguments 2. New user-facing syntax: `type p` patterns (represented by EmbTyPat) `type e` expressions (represented by HsEmbTy) 3. Functions with required type arguments (visible forall) can now be defined and applied: idv :: forall a -> a -> a -- signature (relevant change: checkVdqOK in GHC/Tc/Validity.hs) idv (type a) (x :: a) = x -- definition (relevant change: tcPats in GHC/Tc/Gen/Pat.hs) x = idv (type Int) 42 -- usage (relevant change: tcInstFun in GHC/Tc/Gen/App.hs) 4. template-haskell support: TH.TypeE corresponds to HsEmbTy TH.TypeP corresponds to EmbTyPat 5. Test cases and a new User's Guide section Changes *not* included here are the t2t (term-to-type) transformation and term variable capture; those belong to part 2.
33b6850a -
-
83cbc672
-
This commit integrates ghc-toolchain, the brand new way of configuring toolchains for GHC, with the Hadrian build system, with configure, and extends and improves the first iteration of ghc-toolchain. The general overview is * We introduce a program invoked `ghc-toolchain --triple=...` which, when run, produces a file with a `Target`. A `GHC.Toolchain.Target.Target` describes the properties of a target and the toolchain (executables and configured flags) to produce code for that target * Hadrian was modified to read Target files, and will both * Invoke the toolchain configured in the Target file as needed * Produce a `settings` file for GHC based on the Target file for that stage * `./configure` will invoke ghc-toolchain to generate target files, but it will also generate target files based on the flags configure itself configured (through `.in` files that are substituted) * By default, the Targets generated by configure are still (for now) the ones used by Hadrian * But we additionally validate the Target files generated by ghc-toolchain against the ones generated by configure, to get a head start on catching configuration bugs before we transition completely. * When we make that transition, we will want to drop a lot of the toolchain configuration logic from configure, but keep it otherwise. * For each compiler stage we should have 1 target file (up to a stage compiler we can't run in our machine) * We just have a HOST target file, which we use as the target for stage0 * And a TARGET target file, which we use for stage1 (and later stages, if not cross compiling) * Note there is no BUILD target file, because we only support cross compilation where BUILD=HOST * (for more details on cross-compilation see discussion on !9263) See also * Note [How we configure the bundled windows toolchain] * Note [ghc-toolchain consistency checking] * Note [ghc-toolchain overview] Ticket: #19877 MR: !926331dcd26c -
This flag is disabled by default, and we'll use the configure-generated-toolchains by default until we remove the toolchain configuration logic from configure.
a732b6d3 -
In light of #23690, we split the ghc-toolchain executable out of the library package to be able to ship it in the bindist using Hadrian. Ideally, we eventually revert this commit.
61eea240 -
Add the ghc-toolchain binary to the binary distribution we ship to users, and teach the bindist configure to use the existing ghc-toolchain.
38e795ff -
The relevant primop descriptions are now generated directly by genprimopcode. This makes progress toward fixing #23490, but it is not a complete fix since there is more than one way in which cabal-reinstall (hadrian/build build-cabal) is broken.
32cae784 -
Fixes #23712
02e6a6ce -
There is still something quite unsavoury going on with WARNING pragma printing because the printing relies on the fact that for decl deprecations the SourceText of WarningTxt is empty. However, I let that lion sleep and just fixed things directly. Fixes #23465
822ef66b -
The test-bootstrap job has been failing for 9.6 because we accidentally used a non-master commit.
e7b38ede -
bb408936
-
Use the HasLoc instance from Ast.hs to allow comb4/comb5 to work with anything with a SrcSpan Also get rid of some more now unnecessary reLoc calls.
355e1792 -
Fixes #23503. Now the `-ddump-asm` flag is respected in the wasm backend NCG, so developers can directly view the generated ASM instead of needing to pass `-S` or `-keep-tmp-files` and manually find & open the assembly file. Ideally, we should be able to output the assembly files in smaller chunks like in other NCG backends. This would also make dumping assembly stats easier. However, this would require a large refactoring, so for short-term debugging purposes I think the current approach works fine. Signed-off-by:
Gavin Zhao <git@gzgz.dev>
9393df83 -
Fixes #23711
79463036 -
This commit fixes building ghc with 9.2 as the boostrap compiler. The ghc-toolchain patch assumed all _STAGE0 options were available, and forgot to account for this missing information in 9.2. Ghc 9.2 does not have in settings whether ar supports -l, hence can't report it with --info (unliked 9.4 upwards). The fix is to default the missing information (we default "ar supports -l" and other missing options to False)
20db7e26 -
fac9e84e
-
It adds a warning -Wincomplete-record-selectors for usages of a record field access function (either a record selector or getField @"rec"), while trying to silence the warning whenever it can be sure that a constructor without the record field would not be invoked (which would otherwise cause the program to fail). For example: data T = T1 | T2 {x :: Bool} f a = x a -- this would throw an error g T1 = True g a = x a -- this would not throw an error h :: HasField "x" r Bool => r -> Bool h = getField @"x" j :: T -> Bool j = h -- this would throw an error because of the `HasField` -- constraint being solved See the tests DsIncompleteRecSel* and TcIncompleteRecSel for more examples of the warning. See Note [Detecting incomplete record selectors] in GHC.HsToCore.Expr for implementation details503fd647 -
af6fdf42
-
There have been two incidents recently where bootstrapping has been broken by removing support for building with 9.2.*. The process for bumping the minimum required version starts with bumping the configure version and then other CI jobs such as the bootstrap jobs have to be updated. We must not silently bump the minimum required version. Now we are running a slimmed down validate pipeline it seems worthwile to test these bootstrap configurations in the full-ci pipeline.
5d45b92a -
We are anticipating shortly making it necessary to use ghc-9.4 to boot the compiler.
25d4fee7 -
Fixes #23735
2f66da16 -
This saves on building one dependency (QuickCheck) which is unecessary for bootstrapping.
c8c6eab1 -
-
EquationInfo currently contains a list of the equation's patterns together with a CoreExpr that is to be evaluated after a successful match on this equation. All the match-functions only operate on the first pattern of an equation - after successfully matching it, match is called recursively on the tail of the pattern list. We can express this more clearly and make the code a little more elegant by updating the datatype of EquationInfo as follows: data EquationInfo = EqnMatch { eqn_pat = Pat GhcTc, eqn_rest = EquationInfo } | EqnDone { eqn_rhs = MatchResult CoreExpr } An EquationInfo now explicitly exposes its first pattern which most functions operate on, and exposes the equation that remains after processing the first pattern. An EqnDone signifies an empty equation where the CoreExpr can now be evaluated.a5319358 -
86ad1af9 -
Previously `ghc-prim`'s atomic wrappers used the legacy `__sync_*` family of C builtins. Here we refactor these to rather use the appropriate C11 atomic equivalents, allowing us to be more explicit about the expected ordering semantics.
f8fa1d08 -
The -haddock flag determines whether or not the resulting .hi files contain haddock documentation strings. If the existing .hi files do not contain haddock documentation strings and the user requests them, we should recompile.
0bfc8908 -
Try to generate instr x2, <imm> instead of mov x1, lit instr x2, x1 When possible. This get's rid if quite a few redundant mov instructions. I believe this causes a metric decrease for LargeRecords as we reduce register pressure. ------------------------- Metric Decrease: LargeRecord -------------------------40425c50 -
Resolves #23741 Metric Decrease: MultiComponentModules MultiComponentModulesRecomp MultiLayerModules MultiLayerModulesRecomp T10421 T12234 T12425 T13035 T13701 T13719 T16875 T18304 T18698a T18698b T21839c T9198 TcPlugin_RewritePerf hard_hole_fits Metric decrease on Windows can be probably attributed to https://github.com/haskell/filepath/pull/183
e9a0fa3f -
-
This MR addresses #22404. There is a big Note Note [Occurrence analysis for join points] that explains it all. Significant changes * New field occ_join_points in OccEnv * The NonRec case of occAnalBind splits into two cases: one for existing join points (which does the special magic for Note [Occurrence analysis for join points], and one for other bindings. * mkOneOcc adds in info from occ_join_points. * All "bring into scope" activity is centralised in the new function `addInScope`. * I made a local data type LocalOcc for use inside the occurrence analyser It is like OccInfo, but lacks IAmDead and IAmALoopBreaker, which in turn makes computationns over it simpler and more efficient. * I found quite a bit of allocation in GHC.Core.Rules.getRules so I optimised it a bit. More minor changes * I found I was using (Maybe Arity) a lot, so I defined a new data type JoinPointHood and used it everwhere. This touches a lot of non-occ-anal files, but it makes everything more perspicuous. * Renamed data constructor WithUsageDetails to WUD, and WithTailUsageDetails to WTUD This also fixes #21128, on the way. --------- Compiler perf ----------- I spent quite a time on performance tuning, so even though it does more than before, the occurrence analyser runs slightly faster on average. Here are the compile-time allocation changes over 0.5% CoOpt_Read(normal) ghc/alloc 766,025,520 754,561,992 -1.5% CoOpt_Singletons(normal) ghc/alloc 759,436,840 762,925,512 +0.5% LargeRecord(normal) ghc/alloc 1,814,482,440 1,799,530,456 -0.8% PmSeriesT(normal) ghc/alloc 68,159,272 67,519,720 -0.9% T10858(normal) ghc/alloc 120,805,224 118,746,968 -1.7% T11374(normal) ghc/alloc 164,901,104 164,070,624 -0.5% T11545(normal) ghc/alloc 79,851,808 78,964,704 -1.1% T12150(optasm) ghc/alloc 73,903,664 71,237,544 -3.6% GOOD T12227(normal) ghc/alloc 333,663,200 331,625,864 -0.6% T12234(optasm) ghc/alloc 52,583,224 52,340,344 -0.5% T12425(optasm) ghc/alloc 81,943,216 81,566,720 -0.5% T13056(optasm) ghc/alloc 294,517,928 289,642,512 -1.7% T13253-spj(normal) ghc/alloc 118,271,264 59,859,040 -49.4% GOOD T15164(normal) ghc/alloc 1,102,630,352 1,091,841,296 -1.0% T15304(normal) ghc/alloc 1,196,084,000 1,166,733,000 -2.5% T15630(normal) ghc/alloc 148,729,632 147,261,064 -1.0% T15703(normal) ghc/alloc 379,366,664 377,600,008 -0.5% T16875(normal) ghc/alloc 32,907,120 32,670,976 -0.7% T17516(normal) ghc/alloc 1,658,001,888 1,627,863,848 -1.8% T17836(normal) ghc/alloc 395,329,400 393,080,248 -0.6% T18140(normal) ghc/alloc 71,968,824 73,243,040 +1.8% T18223(normal) ghc/alloc 456,852,568 453,059,088 -0.8% T18282(normal) ghc/alloc 129,105,576 131,397,064 +1.8% T18304(normal) ghc/alloc 71,311,712 70,722,720 -0.8% T18698a(normal) ghc/alloc 208,795,112 210,102,904 +0.6% T18698b(normal) ghc/alloc 230,320,736 232,697,976 +1.0% BAD T19695(normal) ghc/alloc 1,483,648,128 1,504,702,976 +1.4% T20049(normal) ghc/alloc 85,612,024 85,114,376 -0.6% T21839c(normal) ghc/alloc 415,080,992 410,906,216 -1.0% GOOD T4801(normal) ghc/alloc 247,590,920 250,726,272 +1.3% T6048(optasm) ghc/alloc 95,699,416 95,080,680 -0.6% T783(normal) ghc/alloc 335,323,384 332,988,120 -0.7% T9233(normal) ghc/alloc 709,641,224 685,947,008 -3.3% GOOD T9630(normal) ghc/alloc 965,635,712 948,356,120 -1.8% T9675(optasm) ghc/alloc 444,604,152 428,987,216 -3.5% GOOD T9961(normal) ghc/alloc 303,064,592 308,798,800 +1.9% BAD WWRec(normal) ghc/alloc 503,728,832 498,102,272 -1.1% geo. mean -1.0% minimum -49.4% maximum +1.9% In fact these figures seem to vary between platforms; generally worse on i386 for some reason. The Windows numbers vary by 1% espec in benchmarks where the total allocation is low. But the geom mean stays solidly negative, which is good. The "increase/decrease" list below covers all platforms. The big win on T13253-spj comes because it has a big nest of join points, each occurring twice in the next one. The new occ-anal takes only one iteration of the simplifier to do the inlining; the old one took four. Moreover, we get much smaller code with the new one: New: Result size of Tidy Core = {terms: 429, types: 84, coercions: 0, joins: 14/14} Old: Result size of Tidy Core = {terms: 2,437, types: 304, coercions: 0, joins: 10/10} --------- Runtime perf ----------- No significant changes in nofib results, except a 1% reduction in compiler allocation. Metric Decrease: CoOpt_Read T13253-spj T9233 T9630 T9675 T12150 T21839c LargeRecord MultiComponentModulesRecomp T10421 T13701 T10421 T13701 T12425 Metric Increase: T18140 T9961 T18282 T18698a T18698b T19695
d0369802 -
42aa7fbd -
33598ecb
-
This commit implements the ability to deprecate certain instances, which causes the compiler to emit the desired deprecation message whenever they are instantiated. For example: module A where class C t where instance {-# DEPRECATED "dont use" #-} C Int where module B where import A f :: C t => t f = undefined g :: Int g = f -- "dont use" emitted here The implementation is as follows: - In the parser, we parse deprecations/warnings attached to instances: instance {-# DEPRECATED "msg" #-} Show X deriving instance {-# WARNING "msg2" #-} Eq Y (Note that non-standalone deriving instance declarations do not support this mechanism.) - We store the resulting warning message in `ClsInstDecl` (respectively, `DerivDecl`). In `GHC.Tc.TyCl.Instance.tcClsInstDecl` (respectively, `GHC.Tc.Deriv.Utils.newDerivClsInst`), we pass on that information to `ClsInst` (and eventually store it in `IfaceClsInst` too). - Finally, when we solve a constraint using such an instance, in `GHC.Tc.Instance.Class.matchInstEnv`, we emit the appropriate warning that was stored in `ClsInst`. Note that we only emit a warning when the instance is used in a different module than it is defined, which keeps the behaviour in line with the deprecation of top-level identifiers. Signed-off-by:Bartłomiej Cieślar <bcieslar2001@gmail.com>
d2bedffd -
d5a65af6
-
This ensures that Task.h can be built with a C++ compiler.
7218c80a -
d6d5aafc
-
d9eddf7a
-
This allows fine-grained ignoring of warnings.
f9eea4ba -
Previously we would perform a redundant load in the non-threaded RTS in atomicModifyMutVar2# implementation for the benefit of the non-moving GC's write barrier. Eliminate this.
497b24ec -
52ee082b
-
cd3c0377
-
6df2352a
-
4ef6f319
-
f9ca7e27
-
df4153ac
-
fecae988
-
Use the whole declaration, rather than just the span of the 'import' keyword. Metric Decrease: T9961 T5205 Metric Increase: T13035
465a9a0b -
-
Combine some alternatives. Add some line breaks for overly long lines
00fb6e6b -
When the offset doesn't fit into the immediate we now just reuse the general getRegister' code path which is well optimized to compute the offset into a register instead of a special case for CmmRegOff. This means we generate a lot less code under certain conditions which is why performance metrics for these improve. ------------------------- Metric Decrease: T4801 T5321FD T5321Fun -------------------------8f3b3b78 -
See https://github.com/haskell/core-libraries-committee/issues/175 Metric Increase: T18282
74a882dc -
-
This commits adds more performant Enum Int64 and Enum Word64 instances for 32-bit platforms, replacing the Integer-based implementation. These instances are a copy of the Enum Int and Enum Word instances with minimal changes to manipulate Int64 and Word64 instead. On i386 this yields a 1.5x performance increase and for the JavaScript back end it even yields a 5.6x speedup. Metric Decrease: T18964622b483c -
c8bd7fa4
-
b9d5bfe9
-
Warnings when building Hadrian can end up cluttering the output of HLS, and we've had bug reports in the past about these warnings when building Hadrian. It would be nice to turn on -Werror on at least one build of Hadrian in CI to avoid a patch introducing warnings when building Hadrian. Fixes #23638
28211215 -
By using a proper release store instead of a fence.
aca20a5d -
This was the cause of #23541.
453c0531 -
93a0d089
-
This reverts commit 522bd584. And takes care of the case that I missed in my previous attempt. Namely the case of an AbsBinds with no type variables and no dictionary variable. Ironically, the comment explaining why non-recursive lets were desugared to recursive lets were pointing specifically at this case as the reason. I just failed to understand that it was until Simon PJ pointed it out to me. See #23550 for more discussion.
6a2f4a20 -
-
-
Gergő Érdi authored
Closes #23172
e2c91bff -
Gergő Érdi authored
incoherent instances Fixes #23287
5ff82c73
Showing
- .gitlab-ci.yml 30 additions, 10 deletions.gitlab-ci.yml
- .gitlab/gen-ci.cabal 0 additions, 18 deletions.gitlab/gen-ci.cabal
- .gitlab/generate-ci/gen_ci.hs 20 additions, 10 deletions.gitlab/generate-ci/gen_ci.hs
- .gitlab/generate-ci/hie.yaml 0 additions, 0 deletions.gitlab/generate-ci/hie.yaml
- .gitlab/jobs.yaml 85 additions, 85 deletions.gitlab/jobs.yaml
- .gitlab/merge_request_templates/Default.md 5 additions, 1 deletion.gitlab/merge_request_templates/Default.md
- compiler/GHC/Builtin/Names.hs 1 addition, 40 deletionscompiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Names/TH.hs 21 additions, 37 deletionscompiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Builtin/gen_bytearray_addr_access_ops.py 0 additions, 201 deletionscompiler/GHC/Builtin/gen_bytearray_addr_access_ops.py
- compiler/GHC/Builtin/primops.txt.pp 18 additions, 2 deletionscompiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm/MachOp.hs 21 additions, 1 deletioncompiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y 1 addition, 1 deletioncompiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ThreadSanitizer.hs 40 additions, 37 deletionscompiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm.hs 1 addition, 1 deletioncompiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs 207 additions, 83 deletionscompiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs 10 additions, 7 deletionscompiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs 1 addition, 0 deletionscompiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/AArch64/Regs.hs 9 additions, 0 deletionscompiler/GHC/CmmToAsm/AArch64/Regs.hs
- compiler/GHC/CmmToAsm/Ppr.hs 4 additions, 0 deletionscompiler/GHC/CmmToAsm/Ppr.hs
- compiler/GHC/CmmToAsm/Reg/Liveness.hs 9 additions, 7 deletionscompiler/GHC/CmmToAsm/Reg/Liveness.hs
.gitlab/gen-ci.cabal
deleted
100644 → 0