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
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-bounces@haskell.org] On Behalf Of Matthew
| Pickering
| Sent: 15 September 2017 16:46
| To: GHC developers
participants (2)
-
Matthew Pickering -
Simon Peyton Jones