#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