| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
In GHC, not in the code being compiled!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This patch adds the fixes that allow for file names containing spaces to
be passed to GHCi's ':script' command to the release notes for 8.12 and
expands the user-guide documentation for ':script' by mentioning how
such file names can be passed.
Related to #18027.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the user interface of GHCi so that file names passed
to the ':script' command can be wrapped in double quotes.
For example:
:script "foo bar.script"
The implementation uses a modified version of 'words' that treats
character sequences enclosed in double quotes as single words.
Fixes #18027.
|
| |
|
|
|
|
|
|
| |
The syntax for GHCi's ":script" command allows for only a single file
name to be passed as an argument. This patch adds a test for the cases
in which a file name is missing or multiple file names are passed.
Related to #T18027.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the user interface of GHCi so that file names passed
to the ':script' command may contain spaces escaped with a backslash.
For example:
:script foo\ bar.script
The implementation uses a modified version of 'words' that does not
break on escaped spaces.
Fixes #18027.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #18053 we ended up with a suboptimal code layout because
the code layout algorithm didn't distinguish between conditional
and unconditional control flow.
We can completely eliminate unconditional control flow instructions
by placing blocks next to each other, not so much for conditionals.
In terms of implementation we simply give conditional branches less
weight before computing the layout.
Fixes #18053
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When assigning registers we now first try registers we
assigned to in the past, instead of picking the "first"
one.
This is in extremely helpful when dealing with loops for
which variables are dead for part of the loop.
This is important for patterns like this:
foo = arg1
loop:
use(foo)
...
foo = getVal()
goto loop;
There we:
* assign foo to the register of arg1.
* use foo, it's dead after this use as it's overwritten after.
* do other things.
* look for a register to put foo in.
If we pick an arbitrary one it might differ from the register the
start of the loop expect's foo to be in.
To fix this we simply look for past register assignments for
the given variable. If we find one and the register is free we
use that register.
This reduces the need for fixup blocks which match the register
assignment between blocks. In the example above between the end
and the head of the loop.
This patch also moves branch weight estimation ahead of register
allocation and adds a flag to control it (cmm-static-pred).
* It means the linear allocator is more likely to assign the hotter
code paths first.
* If it assign these first we are:
+ Less likely to spill on the hot path.
+ Less likely to introduce fixup blocks on the hot path.
These two measure combined are surprisingly effective. Based on nofib
we get in the mean:
* -0.9% instructions executed
* -0.1% reads/writes
* -0.2% code size.
* -0.1% compiler allocations.
* -0.9% compile time.
* -0.8% runtime.
Most of the benefits are simply a result of removing redundant moves
and spills.
Reduced compiler allocations likely are the result of less code being
generated. (The added lookup is mostly non-allocating).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is rather confusing that when lint finds an error in a rule attached
to a binder, it reports the error as in the RHS, not the rule:
...
In the RHS of foo
We add a clarifying line:
...
In the RHS of foo
In a rule attached to foo
The implication that the rule lives inside the RHS is a bit odd, but
this niggle is already present for unfoldings, whose pattern we are
following.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementation for Ticket #16393.
Explicit specificity allows users to manually create inferred type variables,
by marking them with braces.
This way, the user determines which variables can be instantiated through
visible type application.
The additional syntax is included in the parser, allowing users to write
braces in type variable binders (type signatures, data constructors etc).
This information is passed along through the renamer and verified in the
type checker.
The AST for type variable binders, data constructors, pattern synonyms,
partial signatures and Template Haskell has been updated to include the
specificity of type variables.
Minor notes:
- Bumps haddock submodule
- Disables pattern match checking in GHC.Iface.Type with GHC 8.8
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* GHC.Fingerprint.Types: Fingerprint
* GHC.RTS.Flags: GiveGCStats, GCFlags, ConcFlags, DebugFlags, CCFlags, DoHeapProfile, ProfFlags, DoTrace, TraceFlags, TickyFlags, ParFlags and RTSFlags
* GHC.Stats: RTSStats and GCStats
* GHC.ByteOrder: ByteOrder
* GHC.Unicode: GeneralCategory
* GHC.Stack.Types: SrcLoc
Metric Increase:
haddock.base
|
| |
|
|
|
|
|
|
|
|
|
| |
There are two different Notes named `[When to print foralls]`. The
most up-to-date one is in `GHC.Iface.Type`, but there is a second
one in `GHC.Core.TyCo.Ppr`. The latter is less up-to-date, as it was
written before GHC switched over to using ifaces to pretty-print
types. I decided to just remove the latter and replace it with a
reference to the former.
[ci skip]
|
| |
|
|
|
|
|
|
|
| |
This MachOp was introduced by 2c959a1894311e59cd2fd469c1967491c1e488f3
but a wildcard match in cmmMachOpFoldM hid the fact that it wasn't
handled. Ideally we would eliminate the match but this appears to be a
larger task.
Fixes #18141.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does two things: Fix possible unsoundness in what was called
the "IO hack" and implement part 2.1 of the "fixing precise exceptions"
plan in
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions,
which, in combination with !2956, supersedes !3014 and !2525.
**IO hack**
The "IO hack" (which is a fallback to preserve precise exceptions
semantics and thus soundness, rather than some smart thing that
increases precision) is called `exprMayThrowPreciseException` now.
I came up with two testcases exemplifying possible unsoundness (if
twisted enough) in the old approach:
- `T13380d`: Demonstrating unsoundness of the "IO hack" when resorting
to manual state token threading and direct use of primops.
More details below.
- `T13380e`: Demonstrating unsoundness of the "IO hack" when we have
Nested CPR. Not currently relevant, as we don't have Nested
CPR yet.
- `T13380f`: Demonstrating unsoundness of the "IO hack" for safe FFI
calls.
Basically, the IO hack assumed that precise exceptions can only be
thrown from a case scrutinee of type `(# State# RealWorld, _ #)`. I
couldn't come up with a program using the `IO` abstraction that violates
this assumption. But it's easy to do so via manual state token threading
and direct use of primops, see `T13380d`. Also similar code might be
generated by Nested CPR in the (hopefully not too) distant future, see
`T13380e`. Hence, we now have a more careful test in `forcesRealWorld`
that passes `T13380{d,e}` (and will hopefully be robust to Nested CPR).
**Precise exceptions**
In #13380 and #17676 we saw that we didn't preserve precise exception
semantics in demand analysis. We fixed that with minimal changes in
!2956, but that was terribly unprincipled.
That unprincipledness resulted in a loss of precision, which is tracked
by these new test cases:
- `T13380b`: Regression in dead code elimination, because !2956 was too
syntactic about `raiseIO#`
- `T13380c`: No need to apply the "IO hack" when the IO action may not
throw a precise exception (and the existing IO hack doesn't
detect that)
Fixing both issues in !3014 turned out to be too complicated and had
the potential to regress in the future. Hence we decided to only fix
`T13380b` and augment the `Divergence` lattice with a new middle-layer
element, `ExnOrDiv`, which means either `Diverges` (, throws an
imprecise exception) or throws a *precise* exception.
See the wiki page on Step 2.1 for more implementational details:
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions#dead-code-elimination-for-raiseio-with-isdeadenddiv-introducing-exnordiv-step-21
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Data.IntMap gained a dedicated `disjoint` function in containers-0.6.2.1.
This patch applies this function where appropriate in hopes of modest
compiler performance improvements.
Closes #16806.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Replace some non-deterministic lazy folds with
strict folds.
* Replace some O(n log n) folds in deterministic order
with O(n) non-deterministic folds.
* Replace some folds with set-operations on the underlying
IntMaps.
This reduces max residency when compiling
`nofib/spectral/simple/Main.hs` with -O0 by about 1%.
Maximum residency when compiling Cabal also seems reduced on the
order of 3-9%.
|
| |
|
|
|
|
| |
This reflects the logic present in the Make build system into Hadrian.
Fixes #18167.
|
| |
|
|
| |
Fixes #18166.
|
| | |
|
| |
|
|
|
|
|
| |
This commit adds a link to the user's guide in ghci's
`:help` message.
Newcomers could easily reach to details of ghci.
|
| |
|
|
|
|
|
|
|
|
| |
This commit updates the ghc command's man page as followings:
* Enable `man_show_urls` to show URL addresses in the `DESCRIPTION`
section of ghc.rst, because sphinx currently removes hyperlinks
for man pages.
* Add a `SEE ALSO` section to point to the GHC homepage
|
| |
|
|
| |
Fixes #18142.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements chunks (2) and (3) of
https://gitlab.haskell.org/ghc/ghc/issues/16762#note_270170. Namely,
it introduces a dedicated `HsPatSigType` AST type, which represents
the types that can appear in pattern signatures and term-level `RULE`
binders. Previously, these were represented with `LHsSigWcType`.
Although `LHsSigWcType` is isomorphic to `HsPatSigType`, the intended
semantics of the two types are slightly different, as evidenced by
the fact that they have different code paths in the renamer and
typechecker.
See also the new `Note [Pattern signature binders and scoping]` in
`GHC.Hs.Types`.
|
| |
|
|
|
|
|
|
| |
Makes `interpretPackageEnv` (which loads envirinment files) a part of
`parseDynamicFlags` (parsing command-line arguments, which is typically
done once) instead of `setSessionDynFlags` (which is typically called
several times). Making several (transitive) calls to `interpretPackageEnv`,
as before, caused #18125 #16318, which should be fixed now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Removes mentioning of Hugs
(it is not helpful for new users anymore).
Changes the wording for the rest of the paragraph.
Fixes #18132.
|
| | |
|
| |
|
|
|
| |
Executes the minor formatting change in the tabulated performance
changes suggested in #18135.
|
| |
|
|
| |
Fixes #18074.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, look through expandable unfoldings in `cprTransform`.
See the new Note [CPR for expandable unfoldings]:
```
Long static data structures (whether top-level or not) like
xs = x1 : xs1
xs1 = x2 : xs2
xs2 = x3 : xs3
should not get CPR signatures, because they
* Never get WW'd, so their CPR signature should be irrelevant after analysis
(in fact the signature might even be harmful for that reason)
* Would need to be inlined/expanded to see their constructed product
* Recording CPR on them blows up interface file sizes and is redundant with
their unfolding. In case of Nested CPR, this blow-up can be quadratic!
But we can't just stop giving DataCon application bindings the CPR property,
for example
fac 0 = 1
fac n = n * fac (n-1)
fac certainly has the CPR property and should be WW'd! But FloatOut will
transform the first clause to
lvl = 1
fac 0 = lvl
If lvl doesn't have the CPR property, fac won't either. But lvl doesn't have a
CPR signature to extrapolate into a CPR transformer ('cprTransform'). So
instead we keep on cprAnal'ing through *expandable* unfoldings for these arity
0 bindings via 'cprExpandUnfolding_maybe'.
In practice, GHC generates a lot of (nested) TyCon and KindRep bindings, one
for each data declaration. It's wasteful to attach CPR signatures to each of
them (and intractable in case of Nested CPR).
```
Fixes #18154.
|
| | |
|
| |
|
|
|
| |
Give the NameSet of non-CAFfy names a proper newtype to distinguish it
from all of the other NameSets floating about.
|
| |
|
|
| |
Context: #17153
|
| | |
|
| |
|
|
| |
Revert a change previously made for testing purposes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces residency of compiler quite a bit on some programs.
Example stats when building T10370:
Before:
2,871,242,832 bytes allocated in the heap
4,693,328,008 bytes copied during GC
33,941,448 bytes maximum residency (276 sample(s))
375,976 bytes maximum slop
83 MiB total memory in use (0 MB lost due to fragmentation)
After:
2,858,897,344 bytes allocated in the heap
4,629,255,440 bytes copied during GC
32,616,624 bytes maximum residency (278 sample(s))
314,400 bytes maximum slop
80 MiB total memory in use (0 MB lost due to fragmentation)
So -3.9% residency, -1.3% bytes copied and -0.4% allocations.
Fixes #17497
Metric Decrease:
T9233
T9675
|
| |
|
|
|
|
|
| |
Previously we would implicitly convert the difference between two words
to an int, resulting in an integer overflow on 64-bit machines.
Fixes #16992
|
| |
|
|
|
|
|
|
| |
As noted in #18105, previously this resulted in a rather intrusive error
message. This is in contrast to the general expectation that search
paths are merely places to look, not places that must exist.
Fixes #18105.
|
| |
|
|
|
|
|
| |
This patch allows boot libraries to use unboxed sums without implicitly
depending on `base` package because of `absentSumFieldError`.
See updated Note [aBSENT_SUM_FIELD_ERROR_ID] in GHC.Core.Make
|
