[GHC] #9434: GHC.List.reverse does not fuse

David Feuer david.feuer at gmail.com
Sun Aug 17 23:10:46 UTC 2014


I'm working on it, based on a discussion with Dan Doel. That said,
Haskell's supposed to be anti-pattern, and rewrite/transform/write-back is
definitely a pattern—and a somewhat painful one. Aside from having to use
forms that can be matched on (intentionally blinding the inliner) there's
the unfortunate fact that the written-back forms have to be hand-written
recursive definitions. That's what made me think about a CSE-like cleanup
pass, despite not knowing nearly enough to be able to write it myself just
yet. I wouldn't want full CSE, but rather just to merge identical top-level
lambda forms, which I *think* should avoid potential performance issues
caused by full CSE. Some challenges relating to the idea:

1. It would be very nice if named forms were given preference. So if there
are two copies of \foo -> bar, and the programmer has named one of them
baz, then they should ideally be merged to baz, rather than to quux17. No,
I have no idea what might be involved.

2. In a sufficiently large module, compilation speed could theoretically be
a problem. I don't think this is likely, however, especially since distinct
expressions usually diverge fairly high in their syntax trees.

3. If there are a *lot* of copies of some functions, the copies could make
the Core harder to read. I would conjecture that this will not happen often.
On Aug 17, 2014 6:13 PM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:

>  Well, I’d *much* rather avoid creating the duplication in the first
> place, than to create and try to CSE it away.  Others have suggested ways
> of doing so, following the pattern of existing RULES.
>
>
>
> Simon
>
>
>
> *From:* David Feuer [mailto:david.feuer at gmail.com]
> *Sent:* 15 August 2014 16:41
> *To:* ghc-devs; Simon Peyton Jones
> *Subject:* Re: [GHC] #9434: GHC.List.reverse does not fuse
>
>
>
> I'm having trouble when it doesn't fuse—it ends up with duplicate bindings
> at the top level, because build gets inlined n times, and the result lifted
> out. Nothing's *wrong* with the code, except that there are multiple copies
> of it.
>
> On Aug 15, 2014 10:58 AM, "GHC" <ghc-devs at haskell.org> wrote:
>
> #9434: GHC.List.reverse does not fuse
> -------------------------------------+-------------------------------------
>               Reporter:  dfeuer      |            Owner:
>                   Type:  bug         |           Status:  new
>               Priority:  normal      |        Milestone:
>              Component:              |          Version:  7.9
>   libraries/base                     |         Keywords:
>             Resolution:              |     Architecture:  Unknown/Multiple
>       Operating System:              |       Difficulty:  Easy (less than 1
>   Unknown/Multiple                   |  hour)
>        Type of failure:  Runtime     |       Blocked By:
>   performance bug                    |  Related Tickets:
>              Test Case:              |
>               Blocking:              |
> Differential Revisions:              |
> -------------------------------------+-------------------------------------
>
> Comment (by simonpj):
>
>  Great.  Just check that when fusion ''doesn't'' take place, the result is
>  good. And do a `nofib` comparison for good luck. Then submit a patch.
>
>  Thanks for doing all this work on fusion, David.
>
>  Simon
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9434#comment:2>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140817/ad28218e/attachment.html>


More information about the ghc-devs mailing list