[GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations
GHC
ghc-devs at haskell.org
Mon Nov 30 14:29:09 UTC 2015
#11146: Manual eta expansion leads to orders of magnitude less allocations
-------------------------------------+-------------------------------------
Reporter: niteria | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by niteria):
> Where is the bug in the report?
I'm not convinced this is a bug. I've created this in response to this
comment: https://phabricator.haskell.org/D1537#inline-12820.
> Do you have a (hopefully small and self-contained) bit of code where you
think “duh, obviously the compiler should be a allowed to eta-expand
here”, but it does not?
I can't tell if GHC should be allowed to eta-expand in my example, but the
fact that it decided to eta-expand in a very similar situation where I
didn't have mutually recursive functions suggests that it might be able
to.
> Do things are better if all the relevant code is in one module, with an
explicit export list that does not include any of the functions you’d like
to see eta-expanded?
Yes, it's enough to not export the functions I want eta-expanded.
Unfortunately that's exactly what I want do in Phab:D1537 because I'm
composing a computation from smaller pieces from several modules.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11146#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list