Finding out if a binding is externally visible

[Sebastian Graf]

>
> Occurrence Analyzer


Ahh, good thinking.

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.

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?

On Mon, May 29, 2017 at 5:08 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, den 29.05.2017, 10:40 +0200 schrieb Sebastian Graf:
> > Note that at the bottom,
> > there are RULEs stating the specialization for `Show Integer`, but
> > that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show
> > (Ratio Integer)` isn't otherwise reachable from any exported top-
> > level identifier. Same goes for any of the specialized dictionary
> > methods.
>
> At least the Occurrence Analyzer keeps things referenced from RULES
> alive:
>
>     initial_uds = addManyOccsSet emptyDetails
>                             (rulesFreeVars imp_rules `unionVarSet`
>                              vectsFreeVars vects `unionVarSet`
>                              vectVars)
>     -- The RULES and VECTORISE declarations keep things alive!
>
> So maybe the isExportedId is not the full truths that we are looking
> for here… which would mean that CallArity might be buggy in that
> respect.
>
> This does not contradict Note [ExportFlag on binders] – these IDs do
> not need to be marked Exported, as they are kept alive by the RULE.
> Would we drop, for whatever reason, the RULE, we would drop the id.
>
> > In my case, my custom GHC would substitute away the `showString " %
> > "` for an `absentError "lvl [Char]"` and crash in subtle ways. The
> > only reason this isn't happening for GHC master is that DmdAnal does
> > consider all top-level arguments to be used, instead of only the
> > exported ones (which is what CallArity does).
>
> It seems that CallArity is wrong here, and DmdAnal is right. The way
> out is probably to have CallArity take RULES properly into account.
>
> Greetings,
> Joachim
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170529/4cbffb9a/attachment.html>