Recover gracefully from simplifier tick exhaustion
Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't really be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are
Transformations that must be performed before CorePrep
I hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug.
Transformations that always reduce program size
If a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While RULES are generally wild, it should be safe to apply rules that reduce code size immediately. For example,
foldr c n (build f) ==> f c nis always fine. These transformations can share a tick limit with the mandatory transformations mentioned above.
Transformations that never increase program size
We can be generous with these, but need some limit.
Transformations that may increase program size
These need the harshest limit, of course, but probably not (much?) harsher than what we currently have.
The idea is that even if one tick limit is exceeded, the "higher priority" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.2.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |