Avoiding `OtherCon ` unfoldings, restoring definitions from unfoldings
sgraf1337 at gmail.com
Tue Apr 5 14:12:53 UTC 2022
Top-level data structures tend to get OtherCon  unfoldings when they
are marked NOINLINE.
KindRep bindings are one particular example, and they appear quite
Why are KindReps are NOINLINE? Because (from Note [Grand plan for
The KindReps can unfortunately get quite large. Moreover, the
float out various pieces of them, resulting in numerous top-level
Consequently we mark the KindRep bindings as noinline, ensuring that
float-outs don't make it into the interface file. This is important
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.
------ Originalnachricht ------
Von: "Ben Gamari" <ben at smart-cactus.org>
An: "Simon Peyton Jones" <simon.peytonjones at gmail.com>; "ÉRDI Gergő"
<gergo at erdi.hu>
Cc: "GHC Devs" <ghc-devs at haskell.org>; clash-language at googlegroups.com
Gesendet: 05.04.2022 15:53:02
Betreff: Re: Avoiding `OtherCon ` unfoldings, restoring definitions
>Simon Peyton Jones <simon.peytonjones at 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 .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs