[GHC] #1168: Optimisation sometimes decreases sharing in IO code

GHC trac at galois.com
Tue Feb 5 04:26:54 EST 2008


#1168: Optimisation sometimes decreases sharing in IO code
-------------------------------------+--------------------------------------
 Reporter:  simonmar                 |          Owner:         
     Type:  bug                      |         Status:  new    
 Priority:  normal                   |      Milestone:  _|_    
Component:  Compiler                 |        Version:  6.6    
 Severity:  normal                   |     Resolution:         
 Keywords:                           |     Difficulty:  Unknown
 Testcase:  nofib/spectral/calendar  |   Architecture:  Unknown
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Changes (by simonpj):

 * cc: adam at thejenkins.org (added)

Comment:

 Adding Adam Jenkins to the cc list. At the end of the above thread he
 writes (reasonably enough):

 Thank you for the explanation.  Inlining does explain the behavior I
 was seeing, and `-fno-state-hack` does make the program behave the way
 I'd expect.

 I would like to humbly submit that perhaps this optimization should be
 off by default.  It seems to me that any compiler optimization which
 can potentially increase your program's runtime by an order of
 complexity is dangerous.  Also, while the Haskell Report doesn't seem
 to specify anything about lazy evaluation behavior, it seems to me
 that in order to program in Haskell, assuming that a computation
 assigned to a variable won't be recomputed multiple times is almost as
 necessary an assumption as assuming that the compiler will optimize
 away tail recursion.  For instance GHC FAQ entry 7.2 implicitly
 assumes this is true:

 http://haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F

 In my real program where I ran into this problem it took me quite a
 while to figure out why my program's performance wasn't making any
 sense, and why seemingly irrelevant changes to my code made the
 performance problem go away.

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


More information about the Glasgow-haskell-bugs mailing list