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 |