Overapproximation of loopbreakers due to unfoldings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Overapproximation of loopbreakers due to unfoldings

Matthew Pickering
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Overapproximation of loopbreakers due to unfoldings

GHC - devs mailing list
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:[hidden email]] On Behalf Of Matthew
| Pickering
| Sent: 15 September 2017 16:46
| To: GHC developers <[hidden email]>
| 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
| [hidden email]
| 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs