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

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

More information about the ghc-devs mailing list