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

[Sebastian Graf]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220405/2a90d7e4/attachment.html>