<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Occurrence Analyzer</span></blockquote><div> </div><div>Ahh, good thinking. </div><div><br></div>Do Unfoldings qualify in the same way? Currently, workers all get usage C^w(C^1(...(U))) instead of U in the combined analysis, because they are also not regarded 'externally visible'. There are a lot more one-shot lambdas as a consequence, some of which might not be intuitive: As I understand, the simplifier may inline and share an eta-reduced version of an unfolding from another module at any point. This will not produce incorrect code, but it's a decision that should be made consciously and documented appropriately. <div><br></div><div>So, what binders do I have to consider as 'roots' apart from exports, RULEs, VECTORISE and possibly Unfoldings? That should be pretty much everything relevant, if the occurence analyser gets away with it, right?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 29, 2017 at 5:08 PM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
Am Montag, den 29.05.2017, 10:40 +0200 schrieb Sebastian Graf:<br>
> Note that at the bottom,<br>
> there are RULEs stating the specialization for `Show Integer`, but<br>
> that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show<br>
> (Ratio Integer)` isn't otherwise reachable from any exported top-<br>
> level identifier. Same goes for any of the specialized dictionary<br>
> methods.<br>
<br>
</span>At least the Occurrence Analyzer keeps things referenced from RULES<br>
alive:<br>
<br>
initial_uds = addManyOccsSet emptyDetails<br>
(<wbr>rulesFreeVars imp_rules `unionVarSet`<br>
<wbr>vectsFreeVars vects `unionVarSet`<br>
<wbr>vectVars)<br>
-- The RULES and VECTORISE declarations keep things alive!<br>
<br>
So maybe the isExportedId is not the full truths that we are looking<br>
for here… which would mean that CallArity might be buggy in that<br>
respect.<br>
<br>
This does not contradict Note [ExportFlag on binders] – these IDs do<br>
not need to be marked Exported, as they are kept alive by the RULE.<br>
Would we drop, for whatever reason, the RULE, we would drop the id.<br>
<span class=""><br>
> In my case, my custom GHC would substitute away the `showString " %<br>
> "` for an `absentError "lvl [Char]"` and crash in subtle ways. The<br>
> only reason this isn't happening for GHC master is that DmdAnal does<br>
> consider all top-level arguments to be used, instead of only the<br>
> exported ones (which is what CallArity does).<br>
<br>
</span>It seems that CallArity is wrong here, and DmdAnal is right. The way<br>
out is probably to have CallArity take RULES properly into account.<br>
<div class="HOEnZb"><div class="h5"><br>
Greetings,<br>
Joachim<br>
--<br>
Joachim “nomeata” Breitner<br>
<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a> • <a href="https://www.joachim-breitner.de/" rel="noreferrer" target="_blank">https://www.joachim-breitner.<wbr>de/</a><br>
XMPP: <a href="mailto:nomeata@joachim-breitner.de">nomeata@joachim-breitner.de</a> • OpenPGP-Key: 0xF0FBF51F<br>
Debian Developer: <a href="mailto:nomeata@debian.org">nomeata@debian.org</a></div></div><br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>