| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows we use the function `win32AllocStack` to do stack
allocations in 4k blocks and insert a stack check afterwards
to ensure the allocation returned a valid block.
The problem is this function does something that by C semantics
is pointless. The stack allocated value can never escape the
function, and the stack isn't used so the compiler just optimizes
away the entire function body.
After considering a bunch of other possibilities I think the simplest
fix is to just disable optimizations for the function.
Alternatively inline assembly is an option but the stack check function
doesn't have a very portable name as it relies on e.g. `libgcc`.
Thanks to Sergey Vinokurov for helping diagnose and test.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14669
Differential Revision: https://phabricator.haskell.org/D4343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a parser-level switch to have 'LINE' and 'COLUMN'
pragmas lexed into actual tokens (as opposed to updating the
position information in the parser).
'lexTokenStream' is the only place where this option is enabled.
Reviewers: bgamari, alexbiehl, mpickering
Reviewed By: mpickering
Subscribers: alanz, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4336
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reasons to remove:
- It's confusing - we already have a widely used `Unique` module in
`basicTypes/` that defines a newtype called `Unique`
- `Hoopl.Unique` is not actually used much
I've also moved the `Unique{Map,Set}` from `Hoopl.Unique` to
`Hoopl.Collections` to keep things together. But that module is also a
bit funny - it defines two type-classes that have only one instance
each. So we should probably either remove them or use them more
widely... In any case, that will be a separate change.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Test Plan: ./validate
Reviewers: bgamari, simonmar
Reviewed By: bgamari
Subscribers: kavon, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `splitEnv` worked like this:
> splitEnv "foo:::bar::baz:"
["foo","","","bar","","baz",""]
with this patch:
> splitEnv working_dir "foo:::bar:baz:"
["foo",working_dir,working_dir"bar","baz",working_dir]
This fixes #14695, where having a trailing `:` in the env variable
caused ghci to pass empty `-B` parameter to `gcc`, which in turned
caused the next parameter (`--print-file-name`) to be considered as the
argument to `-B`. As a result ghci did not work.
The `working_dir` argument is to have a similar behavior with POSIX:
according to chapter 8.3 zero-length prefix means current working
directory.
Reviewers: hvr, bgamari, AndreasK, simonmar
Reviewed By: bgamari, AndreasK, simonmar
Subscribers: AndreasK, rwbarton, thomie, carter
GHC Trac Issues: #14695
Differential Revision: https://phabricator.haskell.org/D4330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an initial attempt at tackling the issue of how to order the
suggestions provided by the valid substitutions checker, by sorting
them by creating a graph of how they subsume each other. We'd like to
order them in such a manner that the most "relevant" suggestions are
displayed first, so that the suggestion that the user might be looking
for is displayed before more far-fetched suggestions (and thus also
displayed when they'd otherwise be cut-off by the
`-fmax-valid-substitutions` limit). The previous ordering was based on
the order in which the elements appear in the list of imports, which I
believe is less correlated with relevance than this ordering.
A drawback of this approach is that, since we now want to sort the
elements, we can no longer "bail out early" when we've hit the
`-fmax-valid-substitutions` limit.
Reviewers: bgamari, dfeuer
Reviewed By: dfeuer
Subscribers: dfeuer, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an obvious optimisation whose overhead is neglectable but
which significantly simplifies the common uses of `compareByteArrays#`
which would otherwise require to make *careful* use of
`reallyUnsafePtrEquality#` or (equally fragile) `byteArrayContents#`
which can result in less optimal assembler code being generated.
Test Plan: carefully examined generated cmm/asm code; validate via phab
Reviewers: alexbiehl, bgamari, simonmar
Reviewed By: bgamari, simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding the ability to parse likely flags in Cmm allows better codegen
for cmm files.
Test Plan: ci
Reviewers: bgamari, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14672
Differential Revision: https://phabricator.haskell.org/D4316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's better to fall through to the likely case than to jump to it.
We optimize for this in CmmContFlowOpt when likely:False.
This commit extends the logic there to handle cases with likely:True
as well.
Test Plan: ci
Reviewers: bgamari, simonmar
Reviewed By: bgamari
Subscribers: simonmar, alexbiehl, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4306
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: hvr, dfeuer
Reviewed By: dfeuer
Subscribers: dfeuer, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4304
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GHC-side `getNameToInstancesIndex` filters out incorrectly some
instances because it is not aware of what modules are visible. Using
`runTcInteractive` means that `ie_visible` gets initialized to a one
module set containing some dummy GHCi module. This is clearly not the
module set we want to check against to see if a given orphan instance
is visible or not.
In fact, GHC has no way of knowing what we want that module set to be
since it doesn't know ahead of time which modules Haddock is making its
docs for. The fix is just to pass that set in as an argument.
Bumps haddock submodule.
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: duog, alexbiehl, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4290
|
|
|
|
|
|
| |
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4334
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ideally, I'd like to do
type EvTerm = CoreExpr
and the type checker builds the evidence terms as it goes. This failed,
becuase the evidence for `Typeable` refers to local identifiers that are
added *after* the typechecker solves constraints. Therefore, `EvTerm`
stays a data type with two constructors: `EvExpr` for `CoreExpr`
evidence, and `EvTypeable` for the others.
Delted `Note [Memoising typeOf]`, its reference (and presumably
relevance) was removed in 8fa4bf9.
Differential Revision: https://phabricator.haskell.org/D4341
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [Lone variables] in CoreUnfold and
Note [exprIsExpandable] in CoreUtils.
Helpfully pointed out by Matthew Pickering in Trac #14688
Nofib results are good:
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
anna +0.1% +0.3% 0.151 0.151 0.0%
awards +0.0% -0.2% 0.001 0.001 0.0%
compress2 +0.6% -0.7% -4.8% -5.0% -4.0%
eliza +0.0% -2.4% 0.001 0.001 0.0%
fulsom +0.4% -13.3% -7.6% -7.6% +190.0%
gamteb +0.0% -0.6% 0.062 0.062 0.0%
gg +0.1% -0.4% 0.016 0.016 0.0%
ida +0.1% +0.3% 0.110 0.110 0.0%
kahan +0.0% -0.7% -0.9% -0.9% 0.0%
mate +0.1% -5.2% -4.9% -4.9% 0.0%
n-body +0.0% -0.2% -0.3% -3.0% 0.0%
pretty +0.0% -2.8% 0.000 0.000 0.0%
scs +0.0% -0.2% +1.6% +2.4% 0.0%
simple +0.4% -0.2% -2.3% -2.3% -3.4%
veritas +0.4% -1.0% 0.003 0.003 0.0%
wang +0.0% -1.6% 0.165 0.165 0.0%
--------------------------------------------------------------------------------
Min -0.0% -13.3% -16.2% -18.8% -4.0%
Max +0.6% +0.3% +4.9% +4.9% +190.0%
Geometric Mean +0.1% -0.3% -1.7% -2.4% +0.9%
|
| |
|
| |
|
|
|
|
| |
Richard was confused; I hope these comments help.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a 10% allocation improvement on MultiLayerModules.
The idea is to reuse existing tuples, instead of constantly
constructing new ones.
Test Plan: ./validate
Reviewers: simonpj, bgamari
Reviewed By: simonpj, bgamari
Subscribers: rwbarton, thomie, simonmar, carter
Differential Revision: https://phabricator.haskell.org/D4332
|
|
|
|
|
| |
Not doing so resulted in different uniques being printed on different
environments, as shown in #14703.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Cabal-2.2 uses SPDX license identifiers, so I had to update
`cabal-version: 2.1` packages `license: BSD3` to `license: BSD-3-Clause`
- `ghc-cabal` used old ReadP parsec, now it uses `parsec` too
- InstalledPackageInfo pretty-printing have changed a little,
fields with default values aren't printed. This can be changed in
`Cabal` still, but I haven't found problems with omitting them.
Note: `BSD-3-Clause` is parsed as "name = BSD, version = 3" by old
parser (because 3-Clause looks like version 3 with tag Clause).
If you see *"BSD-3" is not a valid license*, then something is using
old parser still.
Fixes #9885.
|
|
|
|
|
|
| |
I noticed while trying to test against LLVM 5.0 that GHC would throw "Couldn't
figure out linker information" warnings due to LLD being chosen by configure.
Adding detection support to silence these is simple enough, let's just do it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, a list was used as a substitute for a heap.
This led to quadratic behavior on a simple program (see new
test case).
This change replaces it with IntSet in effect reverting
5a1a2633553. @simonmar said it's fine to revert as long as nofib
results are good.
Test Plan:
new test case:
20% improvement
3x improvement when N=10000
nofib:
I run it twice for before and after because the compile time
results are noisy.
- Compile Allocations:
```
before before re-run after after re-run
-1 s.d. ----- -0.0% -0.1% -0.1%
+1 s.d. ----- +0.0% +0.1% +0.1%
Average ----- +0.0% -0.0% -0.0%
```
- Compile Time:
```
before before re-run after after re-run
-1 s.d. ----- -0.1% -2.3% -2.6%
+1 s.d. ----- +5.2% +3.7% +4.4%
Average ----- +2.5% +0.7% +0.8%
```
I checked each case and couldn't find consistent slow-down/speed-up on
compile time. Full results here: P173
Reviewers: simonpj, simonmar, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter, simonmar
GHC Trac Issues: #14667
Differential Revision: https://phabricator.haskell.org/D4329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the proposal of underscores in numeric literals.
Underscores in numeric literals are simply ignored.
The specification of the feature is available here:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/000
9-numeric-underscores.rst
For a discussion of the various choices:
https://github.com/ghc-proposals/ghc-proposals/pull/76
Implementation detail:
* Added dynamic flag
* `NumericUnderscores` extension flag is added for this feature.
* Alex "Regular expression macros" in Lexer.x
* Add `@numspc` (numeric spacer) macro to represent multiple
underscores.
* Modify `@decimal`, `@decimal`, `@binary`, `@octal`, `@hexadecimal`,
`@exponent`, and `@bin_exponent` macros to include `@numspc`.
* Alex "Rules" in Lexer.x
* To be simpler, we have only the definitions with underscores.
And then we have a separate function (`tok_integral` and `tok_frac`)
that validates the literals.
* Validation functions in Lexer.x
* `tok_integral` and `tok_frac` functions validate
whether contain underscores or not.
If `NumericUnderscores` extensions are not enabled,
check that there are no underscores.
* `tok_frac` function is created by merging `strtoken` and
`init_strtoken`.
* `init_strtoken` is deleted. Because it is no longer used.
* Remove underscores from target literal string
* `parseUnsignedInteger`, `readRational__`, and `readHexRational} use
the customized `span'` function to remove underscores.
* Added Testcase
* testcase for NumericUnderscores enabled.
NumericUnderscores0.hs and NumericUnderscores1.hs
* testcase for NumericUnderscores disabled.
NoNumericUnderscores0.hs and NoNumericUnderscores1.hs
* testcase to invalid pattern for NumericUnderscores enabled.
NumericUnderscoresFail0.hs and NumericUnderscoresFail1.hs
Test Plan: `validate` including the above testcase
Reviewers: goldfire, bgamari
Reviewed By: bgamari
Subscribers: carter, rwbarton, thomie
GHC Trac Issues: #14473
Differential Revision: https://phabricator.haskell.org/D4235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename to whitehole_gc_spin, in preparation for adding stats for the
whitehole busy-loop in SMPClosureOps.
Make whitehole_gc_spin volatile, and move it to be defined and
statically initialised in GC.c. This saves some #ifs, and I'm pretty
sure it should be volatile.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an attempt at clarifying the docs for HasCallStack in both the
user guide and libraries/base/GHC/Stack/Types.hs. The example used right
now is built around an hypothetical 'error' function that doesn't itself
print call stacks, and the fact that this doesn't hold makes it all
confusing, see #14635.
Reviewers: hvr, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14635
Differential Revision: https://phabricator.haskell.org/D4317
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A silly mistake in `gen_Show_binds` was causing derived
`Show` instances for empty data types to case on the precedence
argument instead of the actual value being showed.
Test Plan: make test TEST=drv-empty-data
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14692
Differential Revision: https://phabricator.haskell.org/D4328
|
|
|
|
|
|
|
|
| |
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14670
Differential Revision: https://phabricator.haskell.org/D4314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the bit deposit and extraction operations provided
by the BMI and BMI2 instruction set extensions on modern amd64 machines.
Implement x86 code generator for pdep and pext. Properly initialise
bmiVersion field.
pdep and pext test cases
Fix pattern match for pdep and pext instructions
Fix build of pdep and pext code for 32-bit architectures
Test Plan: Validate
Reviewers: austin, simonmar, bgamari, angerman
Reviewed By: bgamari
Subscribers: trommler, carter, angerman, thomie, rwbarton, newhoggy
GHC Trac Issues: #14206
Differential Revision: https://phabricator.haskell.org/D4236
|
|
|
|
|
|
|
|
| |
Subscribers: rwbarton, thomie
GHC Trac Issues: #14335
Differential Revision: https://phabricator.haskell.org/D4202
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that `Convert` was recklessly leaving off
parentheses in two places:
* Negative numeric literals
* Patterns in lambda position
This patch fixes it by adding three new functions, `isCompoundHsLit`,
`isCompoundHsOverLit`, and `isCompoundPat`, and using them in the
right places in `Convert`. While I was in town, I also sprinkled
`isCompoundPat` among some `Pat`-constructing functions in `HsUtils`
to help avoid the likelihood of this problem happening in other
places. One of these places is in `TcGenDeriv`, and sprinkling
`isCompountPat` there fixes #14682
Test Plan: make test TEST="T14681 T14682"
Reviewers: alanz, goldfire, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14681, #14682
Differential Revision: https://phabricator.haskell.org/D4323
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, simonmar
Reviewed By: simonmar
Subscribers: alexbiehl, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4309
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Looking at cmm-dump
Reviewers: bgamari, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4293
|
|
|
|
| |
This reverts commit a1a689dda48113f3735834350fb562bb1927a633.
|
|
|
|
| |
This reverts commit a770226e03f09b767fdb4ce826162a5c0f29ec29.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements SPJ's suggestion on the ticket (#14273). We find the
relevant constraints (ones that whose free unification variables are all
mentioned in the type of the hole), and then clone the free unification
variables of the hole and the relevant constraints. We then add a
subsumption constraints and run the simplifier, and then check whether
all the constraints were solved.
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: RyanGlScott, rwbarton, thomie, carter
GHC Trac Issues: #14273
Differential Revision: https://phabricator.haskell.org/D4315
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14665
Differential Revision: https://phabricator.haskell.org/D4311
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This code is quadratic and a simple test case I used
managed to tickle it.
The example (same one as #14667) looks like this:
```
module A10000 where
data A = A
| A00001
| A00002
...
| A10000
f :: A -> Int
f A00001 = 19900001
f A00002 = 19900002
...
f A10000 = 19910000
```
Applied on top of a fix for #14667, it gives a 30% compile time
improvement.
Test Plan: ./validate
Reviewers: simonpj, bgamari
Subscribers: rwbarton, thomie, simonmar, carter
Differential Revision: https://phabricator.haskell.org/D4307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Substitute RanlibCmd for consistency, and other configure cleanups that
should have no effect
The other commands are so substituted. Maybe we don't need ranlib at
all, and the configure snippet can be removed all together, but that
can always be done later.
Reviewers: bgamari, hvr, angerman
Reviewed By: bgamari, angerman
Subscribers: rwbarton, thomie, erikd, carter
Differential Revision: https://phabricator.haskell.org/D4286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given that we have two unique keys (guaranteed by Map) checking that
`|range| == 1` is faster.
The fact that `x1 == lo` and `x2 == hi` is guaranteed by mkSwitchTargets
which removes values outside of the range.
Test Plan: ci
Reviewers: bgamari, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4295
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows GHC enforces currently that the real executable is named
ghc.exe/ghc-stage[123].exe.
I don't see a good reason why this is neccessary.
This patch removes this restriction and fixes #14652
Test Plan: ci
Reviewers: bgamari, Phyx
Reviewed By: Phyx
Subscribers: Phyx, rwbarton, thomie, carter
GHC Trac Issues: #14652
Differential Revision: https://phabricator.haskell.org/D4296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #14646 happened because we forgot to parenthesize `forall` types to
the left of an arrow. This simple patch fixes that.
Test Plan: make test TEST=T14646
Reviewers: alanz, goldfire, bgamari
Reviewed By: alanz
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14646
Differential Revision: https://phabricator.haskell.org/D4298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flag stops ghci creating the special variable `it`
after evaluating an expression. This stops ghci leaking
as much memory when evaluating expressions. See #14336
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14336
Differential Revision: https://phabricator.haskell.org/D4299
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14653
Differential Revision: https://phabricator.haskell.org/D4305
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, goldfire
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4308
|
|
|
|
|
|
| |
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`LIBRARY_PATH` is used to find libraries and other link artifacts while
`LD_LIBRARY_PATH` is used to find shared libraries by the loader.
Due to an implementation detail on Windows, using `LIBRARY_PATH` will
automatically add the path of any library found to the loader's path.
So in that case `LD_LIBRARY_PATH` won't be needed.
Test Plan:
./validate along with T14611 which has been made Windows only
due to linux using the system linker/loader by default. So I feel a
testcase there is unwarranted as the support is indirect via glibc.
Reviewers: hvr, bgamari, erikd, simonmar, RyanGlScott
Reviewed By: RyanGlScott
Subscribers: RyanGlScott, rwbarton, thomie, carter
GHC Trac Issues: #14611
Differential Revision: https://phabricator.haskell.org/D4275
|