INLINE means "Inline what I wrote". So in your example we'd have
===> bindWith [INLINE = <body mentioning bindWith>] = bindWith_abc |> co bindWith_abc = <optimisied version of body mentioning bindWith> If you see a call to bindWith, we will /not/ inline bindWith_abc |> co! We'll inline <body mentioning bindWith>. That's what the programmer asked for. That's why self-recursive INLINE things are loop breakers. Does that help? Now, it's true that /in the rhs of bindWith_abc/ it might be better to inline (bindWith_abc |> co) in place of bindWith, rather than inlining the <body mentioning bindWith>. But currently GHC can carry only one unfolding for an Id. We could review that, but it'd make things more complicated. I have not yet found time to dig into the mysteries of #14211. Thank you for investigating so diligently. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew | Pickering | Sent: 15 September 2017 16:46 | To: GHC developers <ghc-devs@haskell.org> | Subject: Overapproximation of loopbreakers due to unfoldings | | I have been puzzling over the example presented by Harendra in #14211 for | the last two days. | | Ultimately it led me to discover that if a self-recursive definition is | marked with an INLINE pragma then it will always be marked as a | loopbreaker. | | This is undesirable in this case as the simplifier ends up with in the | first pass.. | | bindWith = ... bindWith ... | => | bindWith = bindWith_abc |> co | bindWith_abc = ... bindWith ... | | So we can then inline `bindWith` into the RHS of `bindWith_abc` and | create a single self-recursive function rather than a mutually recursive | block. Marking `bindWith` as `INLINE` means that both `bindWith` and | `bindWith_abc` are marked as loopbreakers. | | Mutual recursive blocks are bad as they completely stop the static | argument transformation from working. | | My question is, why is it necessary to mark "bindWith" as a loopbreaker | in the current module? Are there any tickets or notes which discuss this | problem? | | Matt | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C2a71eb929ce24b4dcefc08d4fc5 | 0f2db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636410871981371365&sda | ta=RmtbOXJcB9bzKa%2FV95pICCIyTbTfzw1%2BooD52dI%2FzE0%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs