Skip to content

New pattern-match check can be non-performant

In my work in merging D808 (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to pmTraverse, which took 80% of the time, and got called roughly a gajillion times.

To reproduce, simply compile !OptCoercion (with -package ghc) and you'll see your memory usage explode.

So that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file.

There is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help.

NB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today.

Trac metadata
Trac field Value
Version 7.11
Type Bug
TypeOfFailure OtherFailure
Priority highest
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information