diff options
author | Sebastian Graf <sgraf1337@gmail.com> | 2020-10-24 14:03:06 +0200 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2020-10-27 14:05:37 -0400 |
commit | 28f98b01d055c8027f9495b1669bf875b3e42168 (patch) | |
tree | 7acc640e8d81da0249857cbd3ca78a1cf2f74294 /mk/install.mk.in | |
parent | d2a25f42f884ad4ac841a36474498131596da506 (diff) | |
download | haskell-28f98b01d055c8027f9495b1669bf875b3e42168.tar.gz |
DmdAnal: Kill `is_thunk` case in `splitFV`
The `splitFV` function implements the highly dubious hack
described in `Note [Lazy und unleashable free variables]` in
GHC.Core.Opt.DmdAnal. It arranges it so that demand signatures only
carry strictness info on free variables. Usage info is released through
other means, see the Note. It's purely for analysis performance reasons.
It turns out that `splitFV` has a quite involved case for thunks that
produces slightly different usage signatures and it's not clear why we
need it: `splitFV` is only relevant in the LetDown case and the only
time we call it on thunks is for top-level or local recursive thunks.
Since usage signatures of top-level thunks can only reference other
top-level bindings and we completely discard demand info we have on
top-level things (see the lack of `setIdDemandInfo` in
`dmdAnalTopBind`), the `is_thunk` case is completely irrelevant here.
For local, recursive thunks, the added benefit of the `is_thunk` test
is marginal: We get used-multiple-times in some cases where previously
we had used-once if a recursive thunk has multiple call sites. It's
very unlikely and not a case to optimise for.
So we kill the `is_thunk` case and inline `splitFV` at its call site,
exposing `isWeakDmd` from `GHC.Types.Demand` instead.
The NoFib summary supports this decision:
```
Min 0.0% -0.0%
Max 0.0% +0.0%
Geometric Mean -0.0% -0.0%
```
Diffstat (limited to 'mk/install.mk.in')
0 files changed, 0 insertions, 0 deletions