<html><head>
<style id="css_styles" type="text/css"><!--blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] { list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt; }--></style></head>
<body><div>Top-level data structures tend to get OtherCon [] unfoldings when they are marked NOINLINE.</div><div><br /></div><div>KindRep bindings are one particular example, and they appear quite often, too.</div><div><span><br /></span></div><div><span>Why are KindReps are NOINLINE? Because (from </span><span>Note [Grand plan for Typeable])</span></div><div><span><br /></span></div><div> The KindReps can unfortunately get quite large. Moreover, the simplifier will<br /> float out various pieces of them, resulting in numerous top-level bindings.<br /> Consequently we mark the KindRep bindings as noinline, ensuring that the<br /> float-outs don't make it into the interface file. This is important since<br /> there is generally little benefit to inlining KindReps and they would<br /> otherwise strongly affect compiler performance.</div><div><br /></div><div>But perhaps it's not top-level *data structures* without unfoldings that <span>Gergő worries about.</span></div><div><br /></div><div>Sebastian</div><div><br /></div>
<div>------ Originalnachricht ------</div>
<div>Von: "Ben Gamari" <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>></div>
<div>An: "Simon Peyton Jones" <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>>; "ÉRDI Gergő" <<a href="mailto:gergo@erdi.hu">gergo@erdi.hu</a>></div>
<div>Cc: "GHC Devs" <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>>; <a href="mailto:clash-language@googlegroups.com">clash-language@googlegroups.com</a></div>
<div>Gesendet: 05.04.2022 15:53:02</div>
<div>Betreff: Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings</div><div><br /></div>
<div id="x7d0a5a77d2cf4bf" class="plain"><blockquote cite="87y20jskmg.fsf@smart-cactus.org" type="cite" class="cite2">
<tt style="word-wrap:break-word"><div class="plain_line">Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> writes:</div>
<div class="plain_line"> </div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> I don't think any top-level Ids should have OtherCon [] unfoldings? If</div>
<div class="plain_line"> they do, can you give a repro case? OtherCon [] unfoldings usually mean "I</div>
<div class="plain_line"> know this variable is evaluated, but I don't know what its value is. E.g</div>
<div class="plain_line"> data T = MkT !a !a</div>
<div class="plain_line"> f (MkT x y) = ...</div>
<div class="plain_line"> </div>
<div class="plain_line"> here x and y have OtherCon [] unfoldings. They are definitely not bottom!</div>
<div class="plain_line"> </div>
</blockquote>
<div class="plain_line">Is there a reason why we wouldn't potentially give a static data</div>
<div class="plain_line">constructor application an OtherCon [] unfolding? I would guess that</div>
<div class="plain_line">usually these are small enough to have a CoreUnfolding, but in cases</div>
<div class="plain_line">where the expression is too large to have an unstable unfolding we might</div>
<div class="plain_line">rather want to give it an OtherCon [].</div>
<div class="plain_line"> </div>
<div class="plain_line">Cheers,</div>
<div class="plain_line"> </div>
<div class="plain_line">- Ben</div>
<div class="plain_line"> </div>
</tt></blockquote></div>
</body></html>