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

Zubin Duggal 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 
>often, too.
>Why are KindReps are NOINLINE? Because (from Note [Grand plan for 
>  The KindReps can unfortunately get quite large. Moreover, the 
>simplifier will
>  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 
>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 [].
>>- Ben

>ghc-devs mailing list
>ghc-devs at haskell.org

More information about the ghc-devs mailing list