Introduce fast path through simplifier for static bindings
It's not uncommon for early simplifier runs to float out a large number of "static data" bindings from a user program to the top-level. Here we will consider a top-level binding to be "static" if its RHS consists of a data constructor applied to zero or more other static bindings. This floating is quite helpful as static top-levels are represented easily as static code in object code. It also opens an interesting possibility: we know (with a few potential caveats discussed later) no further simplification of these bindings is possible.
However, the simplifier currently does not take advantage of this latter fact: currently the simplifier will dutifully rebuild all bindings on every iteration. This work is wasted effort.
I think it would be helpful to track the "static-ness" of top-level bindings and teach the simplifier and various analyses to ignore bindings so-marked.
Also, there is one caveat here: it is currently possible for users to write rules whose LHSs are headed by a data constructor. This means that further simplification of the bindings which we deemed above as "static" **is** possible. There are two ways of dealing with this,
a. Forbidding data cons in the head of a RULE's LHS b. Check the rule-base for matching rules matching a datacon as "static"
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |