| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generally clean up things relating to Applicative and Monad in `GHC.Base`
and `Control.Applicative` to make `Applicative` feel like a bit more of a
first-class citizen rather than just playing second fiddle to `Monad`. Use
`coerce` and GND to improve performance and clarity.
Change the default definition of `(*>)` to use `(<$)`, in case the
`Functor` instance optimizes that.
Moreover, some manually written instances are made into compiler-derived
instances.
Finally, this also adds a few AMP-related laws to the `Applicative` docstring.
NOTE: These changes result in a 13% decrease in allocation for T9020
Reviewed By: ekmett, hvr
Differential Revision: https://phabricator.haskell.org/D432
|
|
|
|
|
| |
I forget all the details, but I spent some time trying to
understand the current setup, and tried to simplify it a bit
|
|
|
|
|
| |
Authored-by: David Luposchainsky <dluposchainsky@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In many places, 'splitUniqSupply' + 'uniqFromSupply' is used to split a
UniqSupply into a Unique and a new UniqSupply. In such places we should
instead use the more efficient and more appropriate
'takeUniqFromSupply' (or equivalent).
Not only is the former method slower, it also generates and throws away
an extra Unique.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is needed to turn the rule-firings traces into proper output.
|
| |
|
| |
|
|
|
|
|
| |
We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.
|
|
|
|
| |
to deal with very small programs (like zero)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses the rare cases where the simplifier diverges
(see the above ticket). We were already counting how many simplifier
steps were taking place, but with no limit. This patch adds a limit;
at which point we halt compilation, and print out useful stats. The
stats show what is begin inlined, and how often, which points you
directly to the problem. The limit is set based on the size of the
program.
Instead of halting compilation, we could instead just inhibit
inlining, which would let compilation of the module complete. This is
a bit harder to implement, and it's likely to mean that you unrolled
the function 1143 times and then ran out of ticks; you probably don't
want to complete parsing on this highly-unrolled program.
Flags: -dsimpl-tick-factor=N. Default is 100 (percent).
A bigger number increases the allowed maximum tick count.
|
|
|
|
|
|
|
|
|
|
|
| |
Principally, the SimplifierMode now carries several (currently
four) flags in *all* phases, not just the "Gentle" phase.
This makes things simpler and more uniform.
As usual I did more refactoring than I had intended.
This stuff should go into 7.0.2 in due course, once
we've checked it solves the DPH performance problems.
|
|
|
|
|
| |
This patch mainly concerns the plumbing for running
the passes and printing intermediate output
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves a lot of code around, but has zero functionality change.
The idea is that the types
CoreToDo
SimplifierSwitch
SimplifierMode
FloatOutSwitches
and
the main core-to-core pipeline construction
belong in simplCore/, and *not* in DynFlags.
|
|
|
|
|
|
|
| |
This mades -ddump-simpl-stats print out per-rule and per-id
information by default, rather than requiring -dppr-debug.
On the whole that is what you want. The -dppr-debug flag
now just controls printing of the log.
|
|
|
|
|
|
|
| |
This change helps to break the mutual recursion generated by
an instance declaration.
See Note [Gentle mode] in SimplUtils
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch significantly improves the way in which recursive groups
are specialised. This turns out ot be very important when specilising
the bindings that (now) emerge from instance declarations.
Consider
let rec { f x = ...g x'...
; g y = ...f y'.... }
in f 'a'
Here we specialise 'f' at Char; but that is very likely to lead to
a specialisation of 'g' at Char. We must do the latter, else the
whole point of specialisation is lost. This was not happening before.
The whole thing is desribed in
Note [Specialising a recursive group]
Simon
|
|
|
|
|
|
|
| |
We now say
-- {-# SPECIALIZE ...
rather than
{-# -- SPECIALIZE ...
|
| |
|
| |
|
| |
|
|
|
|
| |
Modules that need it import it themselves instead.
|
| |
|
|
|
|
| |
functions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
re-recording to avoid new conflicts was too hard, so I just put it
all in one big patch :-( (besides, some of the changes depended on
each other.) Here are what the component patches were:
Fri Dec 28 11:02:55 EST 2007 Isaac Dupree <id@isaac.cedarswampstudios.org>
* document BreakArray better
Fri Dec 28 11:39:22 EST 2007 Isaac Dupree <id@isaac.cedarswampstudios.org>
* properly ifdef BreakArray for GHCI
Fri Jan 4 13:50:41 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* change ifs on __GLASGOW_HASKELL__ to account for... (#1405)
for it not being defined. I assume it being undefined implies
a compiler with relatively modern libraries but without most
unportable glasgow extensions.
Fri Jan 4 14:21:21 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* MyEither-->EitherString to allow Haskell98 instance
Fri Jan 4 16:13:29 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* re-portabilize Pretty, and corresponding changes
Fri Jan 4 17:19:55 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* Augment FastTypes to be much more complete
Fri Jan 4 20:14:19 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* use FastFunctions, cleanup FastString slightly
Fri Jan 4 21:00:22 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* Massive de-"#", mostly Int# --> FastInt (#1405)
Fri Jan 4 21:02:49 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* miscellaneous unnecessary-extension-removal
Sat Jan 5 19:30:13 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org>
* add FastFunctions
|
| |
|
|
|
|
|
|
|
| |
Older GHCs can't parse OPTIONS_GHC.
This also changes the URL referenced for the -w options from
WorkingConventions#Warnings to CodingStyle#Warnings for the compiler
modules.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Roman produced programs involving associated types that did not optimise well.
His programs were something like this:
data family T a
data instance T Int = MkT Bool Char
bar :: T Int -> Int
bar t = t `seq` loop 0
where
loop = ...
You'd think that the `seq` should unbox 't' outside the loop, since
a (T Int) is just a MkT pair.
The most robust way to make this happen is for the simplifier to understand
a bit about type-family instances. See
Note [Improving seq]
in Simplify.lhs. We use FamInstEnv.topNormaliseType to do the interesting
work.
To make this happen I did a bit of refactoring to the simplifier
monad.
I'd previously done a very similar transformation in LiberateCase, but it
was happening too late. So this patch takes it out of LiberateCase as
well as adding it to Simplify.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a start on removing import lists and generally tidying
up the top of each module. In addition to removing import lists:
- Change DATA.IOREF -> Data.IORef etc.
- Change List -> Data.List etc.
- Remove $Id$
- Update copyrights
- Re-order imports to put non-GHC imports last
- Remove some unused and duplicate imports
|
|
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|