Avoiding `OtherCon ` unfoldings, restoring definitions from unfoldings
zubin at well-typed.com
Tue Apr 5 18:32:06 UTC 2022
Core Tidy also turns CoreUnfoldings to `OtherCon ` while zapping
On 22/04/05 14:12, Sebastian Graf wrote:
>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 .
>ghc-devs mailing list
>ghc-devs at haskell.org
More information about the ghc-devs