Re[2]: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

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" An: "Simon Peyton Jones" ; "ÉRDI Gergő" Cc: "GHC Devs" ; clash-language@googlegroups.com Gesendet: 05.04.2022 15:53:02 Betreff: Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

Simon Peyton Jones 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