[GHC] #7411: Exceptions are optimized away in certain situations

[GHC]

#7411: Exceptions are optimized away in certain situations
-------------------------------------+-------------------------------------
        Reporter:  SimonHengel       |                Owner:  tdammers
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  7.6.1
      Resolution:                    |             Keywords:  seq, deepseq,
                                     |  evaluate, exceptions
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  Incorrect result  |            Test Case:
  at runtime                         |  simplCore/should_fail/T7411
      Blocked By:                    |             Blocking:
 Related Tickets:  #5129 #15225      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Well this is surprising news, but I think good news too.  Maybe we can
 kill off the state hack altogether!

 But before we do that, let's really understand our data.  (A minor point:
 in the nfib-analyse output, the column headings are cut off in the summary
 table; can you use shorter file names?)

 * I'm astounded by the reduction in compile time (and compiler
 allocation), in both variants.  Is that caused by (a) a faster GHC stage
 2, or (b) smaller Core sizes?  Could you pick a module with a particularly
 big reduction, and dig into why?  I confess that I am a bit suspicious.
 Compile times don't usually halve!

 * Binary sizes go up 5% when "GHC is compiled with -fno-state-hack". I
 think that the important thing is that the '''libraries''' (which are
 linked into the nofib binary) are compiled with -fno-state-hack.  I doubt
 it's caused by the fact that ghc-stage2 is compiled with -fno-state-hack.
 Can you confirm?

 * And if binary sizes go up by 5% because the libraries are getting
 bigger, is that a generic 5% increase in .o file size?  Or do a few key
 modules get a lot bigger? It's puzzling because the per-moudule "Module
 Sizes" stats in the nofib log suggest that there is an essentially-zero
 effect on nofib module sizes.

 * As I wrote above, the motivation for the state hack is functions lie
 {{{
 f :: [Int] -> IO ()
 f xs = print ys >> print xs
   where
     ys = reverse xs

 test 0 = return ()
 test n = f [1,n] >> test (n-1)
 }}}
   which I expected to be much less efficient without the state hack.
 Would it be worth trying to demonstrate a program that does get worse in
 this way?  I'm still amazed at how good the results are!

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