Static data and RULES
david at well-typed.com
Fri Feb 17 00:46:58 UTC 2017
On Friday, February 17, 2017 12:33:12 AM EST Simon Peyton Jones via ghc-devs
> The "L" rule becomes problematic when we try to identify static data the
> simplifier shouldn't have to try to optimize. If it identifies LCon 0 as
> static, the "L" rule will never fire.
> Why doesn’t it fire?
> I’m afraid I still do not understand what change is proposed, so I’m finding
> it difficult to see how to fix problems with it.
I'm sorry; I wasn't trying to be obtuse; easy to drop context by mistake. The
idea, at least roughly, is to have a "static" flag on each term. A term is
considered static if it's
1. A Core literal,
2. A nullary constructor, or
3. A constructor whose arguments are all static.
Once a term is flagged static, the simplifier simply shouldn't try to optimize
it--doing so is simply a waste of time.
The trouble is that rules like "L" can turn things that *look* utterly static
into other things, through simplification that we then actually need! So we
need to either try to figure out what's *really* static (which is complicated
by orphan RULES) or we need to let users say so. I jumped for phased INLINE
and NOINLINE pragmas because users are already accustomed to using those to
say "I'm going to match on this with rules". It struck me also as a good way
also to deal with the "S" rule that you've apparently found some other way
More information about the ghc-devs