Top-level data structures tend to get OtherCon [] unfoldings when they
are marked NOINLINE.
KindRep bindings are one particular example, and they appear quite
often, too.
Why are KindReps are NOINLINE? Because (from Note [Grand plan for
Typeable])
The KindReps can unfortunately get quite large. Moreover, the
simplifier will
float out various pieces of them, resulting in numerous top-level
bindings.
Consequently we mark the KindRep bindings as noinline, ensuring that
the
float-outs don't make it into the interface file. This is important
since
there is generally little benefit to inlining KindReps and they would
otherwise strongly affect compiler performance.
But perhaps it's not top-level *data structures* without unfoldings that
Gergő worries about.
Sebastian
------ Originalnachricht ------
Von: "Ben Gamari" <b...@smart-cactus.org>
An: "Simon Peyton Jones" <simon.peytonjo...@gmail.com>; "ÉRDI Gergő"
<ge...@erdi.hu>
Cc: "GHC Devs" <ghc-devs@haskell.org>; clash-langu...@googlegroups.com
Gesendet: 05.04.2022 15:53:02
Betreff: Re: Avoiding `OtherCon []` unfoldings, restoring definitions
from unfoldings
Simon Peyton Jones <simon.peytonjo...@gmail.com> writes:
I don't think any top-level Ids should have OtherCon [] unfoldings? If
they do, can you give a repro case? OtherCon [] unfoldings usually mean "I
know this variable is evaluated, but I don't know what its value is. E.g
data T = MkT !a !a
f (MkT x y) = ...
here x and y have OtherCon [] unfoldings. They are definitely not bottom!
Is there a reason why we wouldn't potentially give a static data
constructor application an OtherCon [] unfolding? I would guess that
usually these are small enough to have a CoreUnfolding, but in cases
where the expression is too large to have an unstable unfolding we might
rather want to give it an OtherCon [].
Cheers,
- Ben
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
