| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Switching to boxyUnify should be enough to fix this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch revives the Static Argument Transformation, thanks to
Max Bolingbroke. It is enabled with
-fstatic-argument-transformation
or -O2
Headline nofib results
Size Allocs Runtime
Min +0.0% -13.7% -21.4%
Max +0.1% +0.0% +5.4%
Geometric Mean +0.0% -0.2% -6.9%
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, GHC should now be printing External Core in a format
that a stand-alone program can parse and typecheck. Major bug fixes:
- The printer now handles qualified/unqualified declarations correctly
(particularly data constructor declarations)
- It prints newtype declarations with enough information to
typecheck code that uses the induced coercions (this required a
syntax change)
- It expands type synonyms correctly
Documentation and external tool patches will follow.
|
|
|
|
|
|
| |
I made the error (which previously said "cannot parse LANGUAGE
pragma") slightly more helpful by reminding the user that pragmas
should be comma-separated.
|
|
|
|
|
|
| |
I changed the "File name does not match module name" error message so
that it prints out both the declared module name and the expected
module name (before, it was only printing the declared module name.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has several advantages:
- -fvia-C is consistent with -fasm with respect to FFI declarations:
both bind to the ABI, not the API.
- foreign calls can now be inlined freely across module boundaries, since
a header file is not required when compiling the call.
- bootstrapping via C will be more reliable, because this difference
in behavour between the two backends has been removed.
There is one disadvantage:
- we get no checking by the C compiler that the FFI declaration
is correct.
So now, the c-includes field in a .cabal file is always ignored by
GHC, as are header files specified in an FFI declaration. This was
previously the case only for -fasm compilations, now it is also the
case for -fvia-C too.
|
|
|
|
| |
Modules that need it import it themselves instead.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Integer, Bool and Unit/Inl/Inr are now in new packages integer
and ghc-prim.
|
|
|
|
|
| |
We were doing lots of cons'ing and tail'ing without forcing the tails,
so were building up lots of thunks.
|
|
|
|
| |
Fixes trac #1893, based on a patch from Daniel Franke.
|
|
|
|
|
| |
This patch removes the ndpFlatten directory and the -fflatten static flag.
This code has never worked and has now been superceded by vectorisation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes a significant improvement to SpecConstr, based on
Roman's experience with using it for stream fusion. The main change is
this:
* For local (not-top-level) declarations, seed the specialisation
loop from the calls in the body of the 'let'.
See Note [Local recursive groups] for discussion and example. Top-level
declarations are treated just as before.
Other changes in this patch:
* New flag -fspec-constr-count=N sets the maximum number of specialisations
for any single function to N. -fno-spec-constr-count removes the limit.
* Refactoring in specLoop and friends; new algebraic data types
OneSpec and SpecInfo instead of the tuples that were there before
* Be less keen to specialise on variables that are simply in scope.
Example
f p q = letrec g a y = ...g.... in g q p
We probably do not want to specialise 'g' for calls with exactly
the arguments 'q' and 'p', since we know nothing about them.
|
|
|
|
|
|
|
|
| |
It turns out that -prof -threaded works (modulo some small changes),
because all the data structures used in profiling are only accessed by
one thread at a time, at long as we don't use +RTS -N2 or higher. So
this patch enables the use of -prof -threaded, but an error is given
if you ask for more than one CPU with +RTS -N.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
GHC panicked with a "Prelude.undefined" error message if you tried to
compile a .hcr file. Since support for reading ExternalCore simply does
not exist, I added an error message to say that.
Please merge to 6.8. Thanks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every simplifier phase can have an arbitrary number of tags and multiple
phases can share the same tags. The tags can be used as arguments to
-ddump-simpl-phases to specify which phases are to be dumped.
For instance, -ddump-simpl-phases=main will dump the output of phases 2, 1 and
0 of the initial simplifier run (they all share the "main" tag) while
-ddump-simpl-phases=main:0 will dump only the output of phase 0 of that run.
At the moment, the supported tags are:
main The main, staged simplifier run (before strictness)
post-worker-wrapper After the w/w split
post-liberate-case After LiberateCase
final Final clean-up run
The names are somewhat arbitrary and will change in the future.
|
|
|
|
|
| |
We can now say -ddump-simpl-phases=1,2 to dump only these two phases and
nothing else.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These fix these failures:
break008(ghci)
break009(ghci)
break026(ghci)
ghci.prog009(ghci)
ghci025(ghci)
print007(ghci)
prog001(ghci)
prog002(ghci)
prog003(ghci)
at least some of which have this symptom:
Exception: expectJust prune
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With constructor unpacking, it's possible for constructors and record
selectors to have non-trivial code, which should be optimised before
being fed to the code generator. Example:
data Foo = Foo { get :: {-# UNPACK #-} !Int }
Then we do not want to get this:
T2070.get =
\ (tpl_B1 :: T2070.Foo) ->
case tpl_B1 of tpl1_B2 { T2070.Foo rb_B4 ->
let {
ipv_B3 [Just S] :: GHC.Base.Int
[Str: DmdType m]
ipv_B3 = GHC.Base.I# rb_B4
} in ipv_B3 }
If this goes through to codegen, we'll generate bad code. Admittedly,
this only matters when the selector is used in a curried way (e.g
map get xs), but nevertheless it's silly.
This patch injects the implicit bindings in SimplCore, before the
simplifier runs. That slows the simplifier a little, because it has
to look at some extra bindings; but it's probably a slight effect.
If it turns out to matter I suppose we can always inject them later,
e.g. just before the final simplification.
An unexpected (to me) consequence is that we get some specialisation rules
for class-method selectors. E.g. we get a rule
RULE (==) Int dInt = eqInt
There's no harm in this, but not much benefit either, because the
same result will happen when we inline (==) and dInt, but it's perhaps
more direct.
|
|
|
|
|
| |
- Also moving all MacOS-specific Makefile components into
distrib/MacOS/Makefile
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|