| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done as a separate `integer-gmp2` backend library because it
turned out to become a complete rewrite from scratch.
Due to the different (over)allocation scheme and potentially different
accounting (via the new `{shrink,resize}MutableByteArray#` primitives),
some of the nofib benchmarks actually results in increased allocation
numbers (but not necessarily an increase in runtime!). I believe the
allocation numbers could improve if `{resize,shrink}MutableByteArray#`
could be optimised to reallocate in-place more efficiently.
Here are the more apparent changes in the latest nofib comparision
between `integer-gmp` and `integer-gmp2`:
------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
------------------------------------------------------------------
...
bernouilli +1.6% +15.3% 0.132 0.132 0.0%
...
cryptarithm1 -2.2% 0.0% -9.7% -9.7% 0.0%
...
fasta -0.7% -0.0% +10.9% +10.9% 0.0%
...
kahan +0.6% +38.9% 0.169 0.169 0.0%
...
lcss -0.7% -0.0% -6.4% -6.4% 0.0%
...
mandel +1.6% +33.6% 0.049 0.049 0.0%
...
pidigits +0.8% +8.5% +3.9% +3.9% 0.0%
power +1.4% -23.8% -18.6% -18.6% -16.7%
...
primetest +1.3% +50.1% 0.085 0.085 0.0%
...
rsa +1.6% +53.4% 0.026 0.026 0.0%
...
scs +1.2% +6.6% +6.5% +6.6% +14.3%
...
symalg +1.0% +9.5% 0.010 0.010 0.0%
...
transform -0.6% -0.0% -5.9% -5.9% 0.0%
...
------------------------------------------------------------------
Min -2.3% -23.8% -18.6% -18.6% -16.7%
Max +1.6% +53.4% +10.9% +10.9% +14.3%
Geometric Mean -0.3% +1.9% -0.8% -0.8% +0.0%
(see P35 / https://phabricator.haskell.org/P35 for full report)
By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results
in the package `integer-gmp-1.0.0.0` being registered in the package db.
The previous `integer-gmp-0.5.1.0` can be restored by setting
`INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether
for GHC 7.12). In-tree GMP support has been stolen from the old
`integer-gmp` (while unpatching the custom memory-allocators, as well as
forcing `-fPIC`)
A minor hack to `ghc-cabal` was necessary in order to support two different
`integer-gmp` packages (in different folders) with the same package key.
There will be a couple of follow-up commits re-implementing some features
that were dropped to keep D82 minimal, as well as further
clean-ups/improvements.
More information can be found via #9281 and
https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2
Reviewed By: austin, rwbarton, simonmar
Differential Revision: https://phabricator.haskell.org/D82
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
#9094 mentions to "remove the RAW_CPP bits from the ghc build system because
they're not longer needed", "once the CPP settings ticket is merged #8683"
#8683 was merged with 34f7e9a3c99850859901ca74370f55f1d4e2279a, Phab:D26.
Test Plan: harbormaster
Reviewers: carter, austin
Reviewed By: austin
Subscribers: simonmar, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D240
GHC Trac Issues: #9094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
would result in
#define __GLASGOW_HASKELL__ 710
#define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
#define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
while GHC 7.10.3 results in
#define __GLASGOW_HASKELL__ 710
#define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
and finally GHC 7.9.20141009 results in
#define __GLASGOW_HASKELL__ 709
#define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
As it's error-prone to properly express CPP conditionals for testing GHC
multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
provided (also via the new CPP include file `ghcversion.h`)
Finally, in order to make it easier to define the new CPP macro
`MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
`include/ghcversion.h` is used for the new CPP definitions.
Reviewed By: ekmett, austin, #ghc
Differential Revision: https://phabricator.haskell.org/D66
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To reproduce build failure it's enough to try
to build GHC on amd64 with the following setup:
$ cat mk/build.mk
# for #9552
GhcWithInterpreter = NO
It gives:
Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Redundant modules: Bitmap BlockId ... <list of 42 modules>
<make error>
dll-split among other things makes sure
all mentioned modules are used by DynFlags.
'#ifdef GHCI' keeps is from happening.
Patch moves those 42 modules under
'GhcWithInterpreter' guard.
Fixes Issue #9552
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a first step toward allowing generic traversals of the AST without 'landmines', by removing the `panic`s located throughout `placeHolderType`, `placeHolderKind` & co.
See more on the discussion at https://www.mail-archive.com/ghc-devs@haskell.org/msg05564.html
(This also makes a corresponding update to the `haddock` submodule.)
Test Plan: `sh validate` and new tests pass.
Reviewers: austin, simonpj, goldfire
Reviewed By: austin, simonpj, goldfire
Subscribers: edsko, Fuuzetsu, thomasw, holzensp, goldfire, simonmar, relrod, ezyang, carter
Projects: #ghc
Differential Revision: https://phabricator.haskell.org/D157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch set makes us no longer assume that a package key is a human
readable string, leaving Cabal free to "do whatever it wants" to allocate
keys; we'll look up the PackageId in the database to display to the user.
This also means we have a new level of qualifier decisions to make at the
package level, and rewriting some Safe Haskell error reporting code to DTRT.
Additionally, we adjust the build system to use a new ghc-cabal output
Make variable PACKAGE_KEY to determine library names and other things,
rather than concatenating PACKAGE/VERSION as before.
Adds a new `-this-package-key` flag to subsume the old, erroneously named
`-package-name` flag, and `-package-key` to select packages by package key.
RFC: The md5 hashes are pretty tough on the eye, as far as the file
system is concerned :(
ToDo: safePkg01 test had its output updated, but the fix is not really right:
the rest of the dependencies are truncated due to the fact the we're only
grepping a single line, but ghc-pkg is wrapping its output.
ToDo: In a later commit, update all submodules to stop using -package-name
and use -this-package-key. For now, we don't do it to avoid submodule
explosion.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D80
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
wiki and mk/config.mk.in suggests setting GhcHcOpts
for compiler-wide haskell flags. But it does not
work for a while now (broke around ca07d92837fc1e3ae9be67bb7d9e7f1b8035b00f)
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: 'make' shows now ghc timing as it used to be
Reviewers: simonmar, austin
Reviewed By: austin
Subscribers: simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D29
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allow the CPP program and flag choices for GHC
be configured via the the ghc settings file
Test Plan: ran validate yesterday
Reviewers: hvr, austin, mzero, simonmar
Reviewed By: austin, mzero, simonmar
Subscribers: mzero, simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D26
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
allowing y ou to assign names to a pattern and abstract over it.
The rundown is this:
* Named patterns are introduced by the new 'pattern' keyword, and can
be either *unidirectional* or *bidirectional*. A unidirectional
pattern is, in the simplest sense, simply an 'alias' for a pattern,
where the LHS may mention variables to occur in the RHS. A
bidirectional pattern synonym occurs when a pattern may also be used
in expression context.
* Unidirectional patterns are declared like thus:
pattern P x <- x:_
The synonym 'P' may only occur in a pattern context:
foo :: [Int] -> Maybe Int
foo (P x) = Just x
foo _ = Nothing
* Bidirectional patterns are declared like thus:
pattern P x y = [x, y]
Here, P may not only occur as a pattern, but also as an expression
when given values for 'x' and 'y', i.e.
bar :: Int -> [Int]
bar x = P x 10
* Patterns can't yet have their own type signatures; signatures are inferred.
* Pattern synonyms may not be recursive, c.f. type synonyms.
* Pattern synonyms are also exported/imported using the 'pattern'
keyword in an import/export decl, i.e.
module Foo (pattern Bar) where ...
Note that pattern synonyms share the namespace of constructors, so
this disambiguation is required as a there may also be a 'Bar'
type in scope as well as the 'Bar' pattern.
* The semantics of a pattern synonym differ slightly from a typical
pattern: when using a synonym, the pattern itself is matched,
followed by all the arguments. This means that the strictness
differs slightly:
pattern P x y <- [x, y]
f (P True True) = True
f _ = False
g [True, True] = True
g _ = False
In the example, while `g (False:undefined)` evaluates to False,
`f (False:undefined)` results in undefined as both `x` and `y`
arguments are matched to `True`.
For more information, see the wiki:
https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation
Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change is to add a case to `reduceTyFamApp_maybe` to evaluate
built-in type constructors (e.g., (+), (*), and friends).
To avoid problems with recursive modules, I moved the definition of
TcBuiltInSynFamily from `FamInst` to `FamInstEnv`. I am still not sure if
this is the right place.
There is also a wibble that it'd be nice to fix:
when we evaluate a built-in type function, using`sfMatchFam`, we get
a `TcCoercion`. However, `reduceTyFamApp_maybe` needs a `Corecion`.
I couldn't find a nice way to convert between the two, so I resorted to
a bit of hack (marked with `XXX`).
The hack is that we happen to know that the built-in constructors for
the type-nat functions always return coercions of shape `TcAxiomRuleCo`,
with no assumptions, so it easy to convert `TcCoercion` to `Coercion`
in this one case. This is enough to make things work, but it is clearly
a cludge.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
width and element type.
SIMD primops are now polymorphic in vector size and element type, but
only internally to the compiler. More specifically, utils/genprimopcode
has been extended so that it "knows" about SIMD vectors. This allows us
to, for example, write a single definition for the "add two vectors"
primop in primops.txt.pp and have it instantiated at many vector types.
This generates a primop in GHC.Prim for each vector type at which "add
two vectors" is instantiated, but only one data constructor for the
PrimOp data type, so the code generator is much, much simpler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit exposes GHC's internal compiler pipeline through a `Hooks`
module in the GHC API. It currently allows you to hook:
* Foreign import/exports declarations
* The frontend up to type checking
* The one shot compilation mode
* Core compilation, and the module iface
* Linking and the phases in DriverPhases.hs
* Quasiquotation
Authored-by: Luite Stegeman <stegeman@gmail.com>
Authored-by: Edsko de Vries <edsko@well-typed.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 6579a6c we removed existing comparison primops and introduced new ones
returning Int# instead of Bool. This commit (and associated commits in
array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
template-haskell) restores old names of primops. This allows us to keep
our API cleaner at the price of not having backwards compatibility.
This patch also temporalily disables fix for #8317 (optimization of
tagToEnum# at Core level). We need to fix #8326 first, otherwise
our primops code will be very slow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible
minimal complete definitions for a class. The body of the pragma is a
boolean formula of names.
The old warning for missing methods is replaced with this new one.
Note: The interface file format is changed to store the minimal complete
definition.
Authored-by: Twan van Laarhoven <twanvl@gmail.com>
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements some simple evaluation of type-level expressions
featuring natural numbers. We can evaluate *concrete* expressions that
use the built-in type families (+), (*), (^), and (<=?), declared in
GHC.TypeLits. We can also do some type inference involving these
functions. For example, if we encounter a constraint such as `(2 + x) ~ 5`
we can infer that `x` must be 3. Note, however, this is used only to
resolve unification variables (i.e., as a form of a constraint improvement)
and not to generate new facts. This is similar to how functional
dependencies work in GHC.
The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
of a new form of axiom called `CoAxiomRule`. This is the form of evidence
generate when we solve a constraint, such as `(1 + 2) ~ 3`.
The patch also adds support for built-in type-families, by adding a new
form of TyCon rhs: `BuiltInSynFamTyCon`. such built-in type-family
constructors contain a record with functions that are used by the
constraint solver to simplify and improve constraints involving the
built-in function (see `TcInteract`). The record in defined in `FamInst`.
The type constructors and rules for evaluating the type-level functions
are in a new module called `TcTypeNats`.
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
unsafeInterleaveIO is used instead of unsafeDupableInterleaveIO because
a mk_supply thunk that is simultaneously entered by two threads should
evaluate to the same UniqSupply.
The UniqSupply counter is now incremented atomically using the RTS's
atomic_inc().
To mitigate the extra overhead of unsafeInterleaveIO in the
single-threaded compiler, noDuplicate# is changed to exit early when
n_capabilities == 1.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 9e133b, the build was modified to pass -fcmm-sink to Parser, but
unfortunately Parser specifies -O0 in its OPTIONS_GHC directive, meaning
the sinking pass was actually turned off.
HC_OPTS is the last thing passed to the compiler for that source file
however, so the correct fix is to also move -O0 out into the build
system as well.
This was uncovered thanks to a build report from Kazu Yamamoto. Thanks
to Jan Stolarek for eyeballing this bug and finding it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
register allocator doesn't run out of stack slots. Previously, we had to
do some CPP hacks in order to emit an #ifdef into the file - this is
because we preprocess it once up front, and run the preprocessor again
when we compile it.
There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
needs the flag, or the stage1 compiler is compiling the stage2
Parser.hs, and needs the flag..
The previous approach was super fragile with Clang. The more principled
fix is to instead do this through the build system.
This fixes #8182.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
|
| |
The solution is to use a different notion of apartness. See
http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/axioms-extended.pdf
for the gory details. Some comments are also in Notes [Compatibility]
and [Apartness] in FamInstEnv.
|
|
|
|
|
| |
When GHCi makes temporary DLLs, those also need to be linked against
the right RTS, or we won't be able to load them.
|
| |
|
|
|
|
|
| |
We used to have to explicitly pass -lffi when linking the compiler,
but it's no longer necessary.
|
|
|
|
| |
Fixes #7780.
|
|
|
|
|
| |
In particular, this means that GHCi will use DLLs, rather than loading
object files itself.
|
|
|
|
|
|
| |
We now put a handful of modules in a separate DLL.
For now the list is hand-written, but we could automate it in the
future.
|
|
|
|
| |
and use them for split
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This makes the build system a little simpler, and in particular
will make it easier to handle the changes needed for cross-compilation.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This removes the '.PHONY' rule, so means that "make" in a built tree
won't repeat the check.
We also now check the .cabal files for the executables as well as the
libraries.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have two cases:
1. building a cross-compiler
2. compiling GHC to run on a foreign platform
These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.
Unfortunately, (2) didn't work, and the build system code needed some
tidying up.
Change to the way the build is set up:
Before
------
To build a cross-compiler:
./configure --target=<..>
To compile a foreign GHC:
./configure --host=<..> --target=<..>
Now
---
To build a cross-compiler:
./configure --target=<..>
And set "Stage1Only=YES" in mk/build.mk
To compile a foreign GHC:
./configure --target=<..>
|
|
|
|
|
|
|
|
|
| |
We want to compile the sources only once, and to produce both vanilla
and dyn object files. This means that the sources can't differ for the
two ways.
This needed a bit of a kludge to get keepCAFsForGHCi included only in
the dynamic library.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
DeriveConstants.hs works in a cross-compilation-friendly way. Rather
than running a C program that prints out the constants, we just compile
a C file which has the constants are encoded in symbol sizes. We then
parse the output of 'nm' to find out what the constants are.
Based on work by Gabor Greif <ggreif@gmail.com>.
|
|
|
|
|
| |
gcc couldn't find ghc_boot_platform.h. I'm not sure why it worked on
Linux.
|
|
|
|
| |
We shouldn't be generating files in the source directories
|
| |
|
| |
|