[GHC] #12620: Allow the user to prevent floating and CSE

GHC ghc-devs at haskell.org
Thu Sep 29 12:17:13 UTC 2016


#12620: Allow the user to prevent floating and CSE
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9520, #8457      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tomjaguarpaw):

 I'm very glad to see full laziness getting some attention.  I've been
 aware of its deleterious effects for some time and have tried to spread
 awareness of it:

 * https://mail.haskell.org/pipermail/haskell-
 cafe/2013-February/106603.html
 * https://mail.haskell.org/pipermail/haskell-
 cafe/2015-December/122526.html
 * https://www.mail-archive.com/haskell-cafe@haskell.org/msg107101.html

 I have even asked whether it is an optimization worth performing at all,
 though I conclude that it is:

 * https://stackoverflow.com/questions/35115172/why-is-full-laziness-a
 -default-optimization/35115664

 The full laziness transformation causes a lot of headaches and something
 ''really'' needs to be done about it.
 However I do not think this suggestion is the right approach.  Why not
 tweak the transformation so that it only fires in cases that are
 guaranteed not to lead to memory leaks?  That could be as simple as only
 hoisting bindings of monomorphic non-recursive datatypes.  The proposed
 `nofloat` keyword is just adding additional complexity over a
 transformation which itself is introducing too much complexity.  I'm very
 concerned about the idea.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12620#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list