| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CmmToLlvm: renamce lcgPlatform -> llvmCgPlatform
CmmToLlvm: rename lcgContext -> llvmCgContext
CmmToLlvm: rename lcgFillUndefWithGarbage
CmmToLlvm: rename lcgSplitSections
CmmToLlvm: lcgBmiVersion -> llvmCgBmiVersion
CmmToLlvm: lcgLlvmVersion -> llvmCgLlvmVersion
CmmToLlvm: lcgDoWarn -> llvmCgDoWarn
CmmToLlvm: lcgLlvmConfig -> llvmCgLlvmConfig
CmmToLlvm: llvmCgPlatformMisc --> llvmCgLlvmTarget
|
| |
|
|
|
|
|
|
|
| |
That is remove factorization of common strings and string building
code for the LLVM code gen ops. Replace these with string literals
to obey the FastString rewrite rule in GHC.Data.FastString and compute
the string length at compile time
|
|
|
|
|
|
|
|
| |
Llvm.Types: remove redundant import
SysTools.Tasks: remove redundant import
- namely CmmToLlvm.Base
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeOutput: LCGConfig, add handshake initLCGConfig
Add two modules:
GHC.CmmToLlvm.Config -- to hold the Llvm code gen config
GHC.Driver.Config.CmmToLlvm -- for initialization, other utils
CmmToLlvm: remove HasDynFlags, add LlvmConfig
CmmToLlvm: add lcgContext to LCGConfig
CmmToLlvm.Base: DynFlags --> LCGConfig
Llvm: absorb LlvmOpts into LCGConfig
CmmToLlvm.Ppr: swap DynFlags --> LCGConfig
CmmToLlvm.CodeGen: swap DynFlags --> LCGConfig
CmmToLlvm.CodeGen: swap DynFlags --> LCGConfig
CmmToLlvm.Data: swap LlvmOpts --> LCGConfig
CmmToLlvm: swap DynFlags --> LCGConfig
CmmToLlvm: move LlvmVersion to CmmToLlvm.Config
Additionally:
- refactor Config and initConfig to hold LlvmVersion
- push IO needed to get LlvmVersion to boundary between Cmm and LLvm
code generation
- remove redundant imports, this is much cleaner!
CmmToLlvm.Config: store platformMisc_llvmTarget
instead of all of platformMisc
|
|
|
|
|
|
|
|
|
|
| |
This adds a new mode, `--merge-objs`, which can be used to produce
merged GHCi library objects.
As future work we will rip out the object-merging logic in Hadrian and
Cabal and instead use this mode.
Closes #20712.
|
|
|
|
| |
A minor refactoring noticed by hlint.
|
|
|
|
| |
This field was entirely unused.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Names defined earier but shadowed need to be kept around, e.g. for type
signatures:
```
ghci> data T = T
ghci> let t = T
ghci> data T = T
ghci> :t t
t :: Ghci1.T
```
and indeed they can be used:
```
ghci> let t2 = Ghci1.T :: Ghci1.T
ghci> :t t2
t2 :: Ghci1.T
```
However, previously this did not happen for ids (non-types), although they
are still around under the qualified name internally:
```
ghci> let t = "other t"
ghci> t'
<interactive>:8:1: error:
• Variable not in scope: t'
• Perhaps you meant one of these:
‘Ghci2.t’ (imported from Ghci2), ‘t’ (line 7), ‘t2’ (line 5)
ghci> Ghci2.t
<interactive>:9:1: error:
• GHC internal error: ‘Ghci2.t’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: []
• In the expression: Ghci2.t
In an equation for ‘it’: it = Ghci2.t
```
This fixes the problem by simply removing the code that tries to remove
shadowed ids from the environment. Now you can refer to shadowed ids using
`Ghci2.t`, just like you can do for data and type constructors. This
simplifies the code, makes terms and types more similar, and also
fixes #20455.
Now all names ever defined in GHCi are in `ic_tythings`, which is printed by
`:show bindings`. But for that commands, it seems to be more ergonomic
to only list those bindings that are not shadowed. Or, even if it is not
more ergonomic, it’s the current behavour. So let's restore that by filtering
in `icInScopeTTs`.
Of course a single `TyThing` can be associated with many names. We keep
it it in the bindings if _any_ of its names are still visible
unqualifiedly. It's a judgement call.
This commit also turns a rather old comment into a test files.
The comment is is rather stale and things are better explained
elsewhere. Fixes #925.
Two test cases are regressing:
T14052(ghci) ghc/alloc 2749444288.0 12192109912.0 +343.4% BAD
T14052Type(ghci) ghc/alloc 7365784616.0 10767078344.0 +46.2% BAD
This is not unexpected; the `ic_tythings list grows` a lot more if we
don’t remove shadowed Ids. I tried to alleviate it a bit with earlier
MRs, but couldn’t make up for it completely.
Metric Increase:
T14052
T14052Type
|
|
|
|
|
|
|
| |
This function expects a singleton list as argument but only checks this
in debug builds. I've added a docstring saying so.
Fixes #20797
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was not possible to refer to a data constructor using
InfixT with a dynamically bound name (i.e. a name with NameFlavour
`NameS` or `NameQ`) if a type constructor of the same
name exists.
This commit adds promoted counterparts to InfixT and UInfixT,
analogously to how PromotedT is the promoted counterpart to ConT.
Closes #20773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the immediate problem that we hash the same file multiple
different times which causes quite a noticeably performance regression.
In the future we can probably do better than this by storing the
implementation hash in the interface file rather than dependending on
hashing the object file.
Related to #20604 which notes some inefficiencies with the current
recompilation logic.
Closes #20790
-------------------------
Metric Decrease:
T14052Type
-------------------------
|
| |
|
|
|
|
|
| |
Previously, `-O1` and `-O2`, by way of their effect on the compilation
pipeline, they implicitly turned on constant folding
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 806e49ae the package imports refactoring code was modified to rename
package imports. There was a small oversight which meant the code didn't
account for module visibility. This patch fixes that oversight.
In general the "lookupPackageName" function is unsafe to use as it
doesn't account for package visiblity/thinning/renaming etc, there is
just one use in the compiler which would be good to audit.
Fixes #20779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Slight decrease but still noticeable on CI:
Baseline
Test Metric value New value Change
-----------------------------------------------------------------------------
ManyAlternatives(normal) ghc/alloc 747607676.0 747458936.0 -0.0%
ManyConstructors(normal) ghc/alloc 4003722296.0 4003530032.0 -0.0%
MultiLayerModules(normal) ghc/alloc 3064539560.0 3063984552.0 -0.0%
MultiLayerModulesRecomp(normal) ghc/alloc 894700016.0 894700624.0 +0.0%
PmSeriesG(normal) ghc/alloc 48410952.0 48262496.0 -0.3%
PmSeriesS(normal) ghc/alloc 61561848.0 61415768.0 -0.2%
PmSeriesT(normal) ghc/alloc 90975784.0 90829360.0 -0.2%
PmSeriesV(normal) ghc/alloc 60405424.0 60259008.0 -0.2%
T10421(normal) ghc/alloc 113275928.0 113137168.0 -0.1%
T10421a(normal) ghc/alloc 79195676.0 79050112.0 -0.2%
T10547(normal) ghc/alloc 28720176.0 28710008.0 -0.0%
T10858(normal) ghc/alloc 180992412.0 180857400.0 -0.1%
T11195(normal) ghc/alloc 283452220.0 283293832.0 -0.1%
T11276(normal) ghc/alloc 137882128.0 137745840.0 -0.1%
T11303b(normal) ghc/alloc 44453956.0 44309184.0 -0.3%
T11374(normal) ghc/alloc 248118668.0 247979880.0 -0.1%
T11545(normal) ghc/alloc 971994728.0 971852696.0 -0.0%
T11822(normal) ghc/alloc 131544864.0 131399024.0 -0.1%
T12150(optasm) ghc/alloc 79336468.0 79191888.0 -0.2%
T12227(normal) ghc/alloc 495064180.0 494943040.0 -0.0%
T12234(optasm) ghc/alloc 57198468.0 57053568.0 -0.3%
T12425(optasm) ghc/alloc 90928696.0 90793440.0 -0.1%
T12545(normal) ghc/alloc 1695417772.0 1695275744.0 -0.0%
T12707(normal) ghc/alloc 956258984.0 956138864.0 -0.0%
T13035(normal) ghc/alloc 102279484.0 102132616.0 -0.1%
T13056(optasm) ghc/alloc 367196556.0 367066408.0 -0.0%
T13253(normal) ghc/alloc 334365844.0 334255264.0 -0.0%
T13253-spj(normal) ghc/alloc 125474884.0 125328672.0 -0.1%
T13379(normal) ghc/alloc 359185604.0 359036960.0 -0.0%
T13701(normal) ghc/alloc 2403026480.0 2402677464.0 -0.0%
T13719(normal) ghc/alloc 4192234752.0 4192039448.0 -0.0%
T14052(ghci) ghc/alloc 2745868552.0 2747706176.0 +0.1%
T14052Type(ghci) ghc/alloc 7335937964.0 7336283280.0 +0.0%
T14683(normal) ghc/alloc 2992557736.0 2992436872.0 -0.0%
T14697(normal) ghc/alloc 363391248.0 363222920.0 -0.0%
T15164(normal) ghc/alloc 1292578008.0 1292434240.0 -0.0%
T15304(normal) ghc/alloc 1279603472.0 1279465944.0 -0.0%
T15630(normal) ghc/alloc 161707776.0 161602632.0 -0.1%
T16190(normal) ghc/alloc 276904644.0 276555264.0 -0.1%
T16577(normal) ghc/alloc 7573033016.0 7572982752.0 -0.0%
T16875(normal) ghc/alloc 34937980.0 34796592.0 -0.4%
T17096(normal) ghc/alloc 287436348.0 287299368.0 -0.0%
T17516(normal) ghc/alloc 1714727484.0 1714617664.0 -0.0%
T17836(normal) ghc/alloc 1091095748.0 1090958168.0 -0.0%
T17836b(normal) ghc/alloc 52467912.0 52321296.0 -0.3%
T17977(normal) ghc/alloc 44971660.0 44826480.0 -0.3%
T17977b(normal) ghc/alloc 40941128.0 40793160.0 -0.4%
T18140(normal) ghc/alloc 82363124.0 82213056.0 -0.2%
T18223(normal) ghc/alloc 1168448128.0 1168333624.0 -0.0%
T18282(normal) ghc/alloc 131577844.0 131440400.0 -0.1%
T18304(normal) ghc/alloc 86988664.0 86844432.0 -0.2%
T18478(normal) ghc/alloc 742992400.0 742871136.0 -0.0%
T18698a(normal) ghc/alloc 337654412.0 337526792.0 -0.0%
T18698b(normal) ghc/alloc 398840772.0 398716472.0 -0.0%
T18923(normal) ghc/alloc 68964992.0 68818768.0 -0.2%
T1969(normal) ghc/alloc 764285884.0 764156168.0 -0.0%
T19695(normal) ghc/alloc 1395577984.0 1395552552.0 -0.0%
T20049(normal) ghc/alloc 89159032.0 89012952.0 -0.2%
T3064(normal) ghc/alloc 191194856.0 191051816.0 -0.1%
T3294(normal) ghc/alloc 1604762016.0 1604656488.0 -0.0%
T4801(normal) ghc/alloc 296829368.0 296687824.0 -0.0%
T5030(normal) ghc/alloc 364720540.0 364580152.0 -0.0%
T5321FD(normal) ghc/alloc 271090004.0 270950824.0 -0.1%
T5321Fun(normal) ghc/alloc 301244320.0 301102960.0 -0.0%
T5631(normal) ghc/alloc 576154548.0 576022904.0 -0.0%
T5642(normal) ghc/alloc 471105876.0 470967552.0 -0.0%
T5837(normal) ghc/alloc 36328620.0 36186720.0 -0.4%
T6048(optasm) ghc/alloc 103125988.0 102981024.0 -0.1%
T783(normal) ghc/alloc 386945556.0 386795984.0 -0.0%
T9020(optasm) ghc/alloc 247835012.0 247696704.0 -0.1%
T9198(normal) ghc/alloc 47556208.0 47413784.0 -0.3%
T9233(normal) ghc/alloc 682210596.0 682069960.0 -0.0%
T9630(normal) ghc/alloc 1429689648.0 1429581168.0 -0.0%
T9675(optasm) ghc/alloc 431092812.0 430943192.0 -0.0%
T9872a(normal) ghc/alloc 1705052592.0 1705042064.0 -0.0%
T9872b(normal) ghc/alloc 2180406760.0 2180395784.0 -0.0%
T9872c(normal) ghc/alloc 1760508464.0 1760497936.0 -0.0%
T9872d(normal) ghc/alloc 501517968.0 501309464.0 -0.0%
T9961(normal) ghc/alloc 354037204.0 353891576.0 -0.0%
TcPlugin_RewritePerf(normal) ghc/alloc 2381708520.0 2381550824.0 -0.0%
WWRec(normal) ghc/alloc 589553520.0 589407216.0 -0.0%
hard_hole_fits(normal) ghc/alloc 492122188.0 492470648.0 +0.1%
hie002(normal) ghc/alloc 9336434800.0 9336443496.0 +0.0%
parsing001(normal) ghc/alloc 537680944.0 537659824.0 -0.0%
geo. mean -0.1%
|
|
|
|
|
|
| |
See #20725.
The commit includes source-code changes and a test case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser now accepts implicit parameters with higher-rank
types, such as
`foo :: (?ip :: forall a. a -> a) => ...`
Before this patch, we instead insisted on parentheses like so:
`foo :: (?ip :: (forall a. a -> a)) => ...`
The rest of the logic surrounding implicit parameters is unchanged;
in particular, even with ImpredicativeTypes, this idiom is not
likely to be very useful.
Fixes #20654
|
|
|
|
|
|
|
|
| |
As noted in #20757, `GHC.SysTools.BaseDir.findToolDir` previously
contained an loop, which would be triggered in the case that the search
failed.
Closes #20757.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2.
This implements the first step in the plan formulated in #20025 to
improve the communication and migration strategy for the proposed
changes to Data.List.
Requires changing the haddock submodule to update the test output.
|
|
|
|
| |
comparison (#20088)
|
|
|
|
|
|
|
| |
C11 rule 6.3.1.1 dictates that all small integers used in expressions be
implicitly converted to `signed int`. However, Cmm semantics require that the
width of the operands be preserved with zero-extension semantics. For
this reason we must recast sub-word arithmetic results as unsigned.
|
|
|
|
|
|
|
| |
As noted in Note [When in doubt, cast arguments as unsigned], we
must ensure that arguments have the correct signedness since some
operations (e.g. `%`) have different semantics depending upon
signedness.
|
|
|
|
|
| |
As noted in Note [Zero-extending sub-word signed results] we must
explicitly zero-extend the results of sub-word-sized signed operations.
|
|
|
|
|
| |
Under C's implicit widening rules, the result of an operation like (a >>
b) where a::Word8 and b::Word will have type Word, yet we want Word.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we rework the handling of sub-word operations in the AArch64
backend, fixing a number of bugs and inconsistencies. In short,
we now impose the invariant that all subword values are represented in
registers in zero-extended form. Signed arithmetic operations are then
responsible for sign-extending as necessary.
Possible future work:
* Use `CMP`s extended register form to avoid burning an instruction
in sign-extending the second operand.
* Track sign-extension state of registers to elide redundant sign
extensions in blocks with frequent sub-word signed arithmetic.
|
|
|
|
|
| |
This is necessary for lint-correctness since we no longer allow such
shifts in Cmm.
|
|
|
|
|
| |
We might be loading, e.g., a 16- or 8-bit value, in which case the
register width is not reflective of the loaded element size.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously primops.txt.pp stipulated that the word-size shift primops
were only defined for shift offsets in [0, word_size). However, there
was no further guidance for the definition of Cmm's sub-word size shift
MachOps.
Here we fix this by explicitly disallowing (checked in many cases by
CmmLint) shift operations where the shift offset is larger than the
shiftee. This is consistent with LLVM's shift operations, avoiding the
miscompilation noted in #20637.
|
|
|
|
|
| |
Previously we would emit the sign-extending LDS[HB] instructions for
sub-word loads. However, this is wrong, as noted in #20638.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the constant-folding behavior for MO_S_Quot and MO_S_Rem
failed to narrow its arguments, meaning that a program like:
%zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8))
would be miscompiled. Specifically, this program should reduce as
%lobits8(0x00e1::bits16) == -31
%quot(%lobits8(0x00e1::bits16), 3::bits8) == -10
%zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) == 246
However, with this bug the `%lobits8(0x00e1::bits16)` would instead
be treated as `+31`, resulting in the incorrect result of `75`.
(cherry picked from commit 94e197e3dbb9a48991eb90a03b51ea13d39ba4cc)
|
|
|
|
|
|
|
|
|
|
|
| |
Handle the case of a shift larger than the width of the shifted value.
This is necessary since x86 applies a mask of 0x1f to the shift amount,
meaning that, e.g., `shr 47, $eax` will actually shift by
47 & 0x1f == 15.
See #20626.
(cherry picked from commit 31370f1afe1e2f071b3569fb5ed4a115096127ca)
|
|
|
|
|
|
|
|
|
| |
- Change the dumpPrefix to FilePath, and default to non-module
- Add dot to seperate dump-file-prefix and suffix
- Modify user guide to introduce how dump files are named
- This commit does not affect Ghci dump file naming.
See also #17500
|
|
|
|
|
|
| |
The goal here is to make the SRT selection logic a bit clearer and allow
configurations which we currently don't support (e.g. using a full word
in the info table even when TNTC is used).
|
|
|
|
|
|
|
|
|
|
| |
It seems to have a moderate but good impact on perf tests in CI.
In particular:
MultiLayerModules(normal) ghc/alloc 3125771138.7 3065532240.0 -1.9%
So it's likely that huge projects will benefit from this.
|
|
|
|
|
|
|
|
| |
There were two ways to indicate that a TTG constructor is unused in a phase:
`NoExtCon` and `Void`. This unifies the code, and uses the name
'DataConCantHappen', following the discussion at MR 7041.
Updates haddock submodule
|
|
|
|
|
|
|
| |
Get rid of `USE_INPLACE_MINGW_TOOLCHAIN` and use a settings file entry
instead.
The CPP setting was originally introduced in f065b6b012.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OverloadedDotSyntax
There are quite a few keywords which are allowed to be used as
variables. Such as "as", "dependency" etc. These weren't accepted by
OverloadedDotSyntax.
The fix is pretty simple, use the varid production rather than raw
VARID.
Fixes #20723
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Previously, when a plugin could not be loaded because it was incorrectly typed, the error message only printed the expected but not the actual type.
This commit augments the error message such that both types are printed and the corresponding module is printed as well.
|
|
|
|
| |
This significantly improves Haddock documentation generated by nix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two different ways of declaring a class in an hs-boot file:
- a full declaration, where everything is written as it is
in the .hs file,
- an abstract declaration, where class methods and superclasses
are left out.
However, a declaration with no methods and a trivial superclass,
such as:
class () => C a
was erroneously considered to be an abstract declaration, because
the superclass is trivial.
This is remedied by a one line fix in GHC.Tc.TyCl.tcClassDecl1.
This patch also further clarifies the documentation around
class declarations in hs-boot files.
Fixes #20661, #20588.
|
| |
|
| |
|
| |
|
| |
|