Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

[Zubin Duggal]

Core Tidy also turns CoreUnfoldings to `OtherCon []` while zapping
unfoldings.

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 
>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" <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 
>from unfoldings
>
>>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 [].
>>
>>Cheers,
>>
>>- Ben
>>

>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs