heads up: GHC gets a new constraint solver (again)

Friends, After a very busy period of hard work with Simon, we've re-engineered GHCs constraint solver and I just pushed a big patch on master along with modifications in the testsuite. The new constraint solver is based on the existing in its core ideas but is shorter, much cuter, and for many programs much faster (for others performance is roughly the same) If you had a program that was taking very long to compile in the past, we'd be very interested to see how this reengineered constraint solver performs on it. Same if you spot problems or notable regressions. Thanks, enjoy! Dimitrios
-----Original Message----- From: cvs-ghc-bounces@haskell.org [mailto:cvs-ghc-bounces@haskell.org] On Behalf Of dimitris@microsoft.com Sent: 16 November 2011 17:42 To: cvs-ghc@haskell.org Subject: [commit: ghc] master: GHC gets a new constraint solver. More efficient and smaller in size. (0007c0e)
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/0007c0ec9c0de68e3a348b8c4 112ac48fd861b1e
---------------------------------------------------------------
commit 0007c0ec9c0de68e3a348b8c4112ac48fd861b1e Author: Dimitrios Vytiniotis
Date: Wed Nov 16 16:12:48 2011 +0000 GHC gets a new constraint solver. More efficient and smaller in size.
compiler/basicTypes/DataCon.lhs | 9 +- compiler/basicTypes/MkId.lhs | 10 +- compiler/codeGen/CgCase.lhs | 18 +- compiler/coreSyn/CoreLint.lhs | 78 +- compiler/coreSyn/CoreSubst.lhs | 15 +- compiler/coreSyn/CoreUtils.lhs | 27 +- compiler/deSugar/Desugar.lhs | 7 +- compiler/deSugar/DsBinds.lhs | 29 +- compiler/deSugar/DsCCall.lhs | 4 +- compiler/deSugar/DsUtils.lhs | 2 +- compiler/hsSyn/HsBinds.lhs | 17 +- compiler/prelude/TysPrim.lhs | 12 +- compiler/simplCore/CoreMonad.lhs | 9 +- compiler/simplCore/OccurAnal.lhs | 4 +- compiler/simplCore/SimplUtils.lhs | 2 +- compiler/simplCore/Simplify.lhs | 25 +- compiler/typecheck/Inst.lhs | 71 +- compiler/typecheck/TcCanonical.lhs | 1361 ++++++++++++++-------- compiler/typecheck/TcErrors.lhs | 48 +- compiler/typecheck/TcHsSyn.lhs | 12 +- compiler/typecheck/TcInteract.lhs | 1664 +++++++++----------------- compiler/typecheck/TcMType.lhs | 40 +- compiler/typecheck/TcRnDriver.lhs | 15 +- compiler/typecheck/TcRnMonad.lhs | 9 + compiler/typecheck/TcRnTypes.lhs | 194 +++- compiler/typecheck/TcSMonad.lhs | 1211 ++++++++++++++------ compiler/typecheck/TcSimplify.lhs | 522 +++++---- compiler/typecheck/TcSplice.lhs | 2 +- compiler/typecheck/TcType.lhs | 41 +- compiler/types/Coercion.lhs | 99 +- compiler/types/FunDeps.lhs | 10 +- compiler/types/Type.lhs | 12 +- compiler/types/TypeRep.lhs | 21 +- compiler/vectorise/Vectorise/Type/PRepr.hs | 4 +- compiler/vectorise/Vectorise/Utils/PADict.hs | 2 +- 35 files changed, 3205 insertions(+), 2401 deletions(-)
Diff suppressed because of size. To see it, use:
git show 0007c0ec9c0de68e3a348b8c4112ac48fd861b1e
_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

On Wednesday 16 November 2011, 19:22:53, Dimitrios Vytiniotis wrote:
Friends,
After a very busy period of hard work with Simon, we've re-engineered GHCs constraint solver and I just pushed a big patch on master along with modifications in the testsuite.
The new constraint solver is based on the existing in its core ideas but is shorter, much cuter, and for many programs much faster (for others performance is roughly the same)
If you had a program that was taking very long to compile in the past, we'd be very interested to see how this reengineered constraint solver performs on it. Same if you spot problems or notable regressions.
Seems to be a clear win for T5030: bytes allocated 943772224 is less than minimum allowed 1200000000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again *** unexpected failure for T5030(normal) :D But due to its greater efficiency, it's dangerous in cases like SkolemOccursLoop. It seems the new solver gets as far with a context-stack of N as the old got with a context-stack of 2N+1 there. When, like in SkolemOccursLoop, the context grows exponentially in size, you're running out of memory even with a relatively small context-stack. Cheers, Daniel
participants (2)
-
Daniel Fischer
-
Dimitrios Vytiniotis