Fun with GHC's optimiser

[Simon Peyton-Jones]

Manuel

OK, I've improved the eta expander so it does a better
job of the code you found.

Try now.  On the HEAD.  Which should compile OK now, incidentally.

How's your parallel Haskell stuff coming?

Simon


| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]
| Sent: 02 November 2000 13:54
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: Fun with GHC's optimiser
| 
| 
| Simon Peyton-Jones <simonpj@microsoft.com> wrote,
| 
| > I can never resist messages like these, even when I'm meant
| > to be doing other things.  
| 
| That's good to know ;-)
| 
| > It's very helpful when people offer
| > fairly precise performance-bug reports.  Thanks!
| 
| Thanks for the prompt reply!  To SimonM, too.
| 
| > | I am wondering whether there is a particular reason why the
| > | optimiser doesn't pull the
| > | 
| > |   (1)  a = NO_CCS PArray! [wild1 mba#];
| > 
| > This one is a definite bug.  It turns out that the head of the
| > before-ghci-branch doesn't have this bug, so I'm disinclined
| > to investigate it further.  
| 
| No problem, I can always build a new ghc from CVS.
| 
| > |   (2)  case w of wild3 {
| > |          I# e# ->
| > | 
| > | As for (2), the loop would be nice and straight if that
| > | unboxing where outside of the loop - as it is, we break the
| > | pipeline once per iteration it seems
| > 
| > This one is a bit harder.  Basically we want to make a wrapper
| > for a recursive function if it's sure to evaluate its free 
| variables.
| > 
| > In fact the 'liberate-case' pass (which isn't switched on in 4.08)
| > is meant to do just this. It's in simplCore/LiberateCase.lhs,
| > and it's not very complicated.  I've just tried it and it 
| doesn't seem
| > to have the desired effect, but I'm sure that's for a boring reason.
| > If anyone would like to fix it, go ahead!
| 
| Ok - something for a rainy weekend, I guess...
| 
| > Incidentally, you'll find that -ddump-simpl gives you a dump that
| > is pretty close to STG and usually much more readable.  Most
| > performance bugs show up there.  -dverbose-simpl gives you more
| > clues about what is happening where.
| 
| Good to know.  I just wasn't sure whether I wouldn't miss
| out on some optimisations.
| 
| > | Also if somebody is looking at the attached source, I was
| > | wondering why, when I use the commented out code in
| > | `newPArray', I get a lot worse code (the STG code is in a
| > | comment at the end of the file).  In particular, the lambda
| > | abstraction is not inlined, whereas `fill' gets inlined into
| > | the code of which the dump is above.  Is it because the
| > | compiler has a lot harder time with explicit recursion than
| > | with fold/build?  If so, the right RULES magic should allow
| > | me to do the same for my own recursively defined
| > | combinators, shouldn't it?
| > 
| > I couldn't figure out exactly what you meant.  The only commented
| > out code is STG code.  Maybe send a module with the actual
| > source you are bothered about.
| 
| Appended the version of the module where the code is
| activated (it was commented out with --) - you'll find the
| problematic code by searching for (**) in the code.  It
| generates
| 
| $w$snewPArray
|   = \ ww :: Int# w :: Int ->
| 	case newIntArray# @ RealWorld ww realWorld#
| 	of wild { (# s2#, mba# #) ->
| 	case $wsimpleGen
| 		 ww
| 		 (\ i :: Int ->
| 		      case i of wild1 { I# i# ->
| 		      case w of wild2 { I# e# ->
| 		      __coerce (ST RealWorld ())
| 		      (\ s# :: (State# RealWorld) ->
| 			   case writeIntArray# @ RealWorld mba# i# e# s#
| 			   of s2#1 { __DEFAULT ->
| 			   (# s2#1, () #)
| 			   })
| 		      }
| 		      })
| 		 s2#
| 	of wild1 { (# new_s, r #) ->
| 	let {
| 	  a :: Int
| 	  a = $wI# ww
| 	} in  (# a, (__coerce ByteArray# mba#) #)
| 	}
| 	}
| 
| One thing that is not nice is in the lambda abstraction
| based to $wsimpleGen.  There is one lambda, then two
| unboxing operations and another lambda for the state
| variables s#.  These two nested lambda's become in STG
| 
| 		stg_c1Op =
| 		    NO_CCS[] \r[i]
| 			case i of wild1 {
| 			  I# i# ->
| 			      case w of wild2 {
| 				I# e# ->
| 				    let {
| 				      stg_c1Sv =
| 					  NO_CCS[] \r[s#]
| 					      case 
| writeIntArray# [mba# i# e# s#] of s2#1 {
| 						DEFAULT -> 
| (#,#) [s2#1 ()]
| 					      };
| 				    } in  stg_c1Sv;
| 			      };
| 			};
| 
| So, stg_c1Sv is allocated and immediately entered.  I would
| have hoped that the two lambda abstractions are merged into
| something like this:
| 
| 		 (\ i :: Int s# :: (State# RealWorld) ->
| 		      case i of wild1 { I# i# ->
| 		      case w of wild2 { I# e# ->
| 		      case writeIntArray# @ RealWorld mba# i# e# s#
| 			   of s2#1 { __DEFAULT -> (# s2#1, () #)
| 		      })
| 		      }
| 		      })
| 
| Maybe it is the __coerce, which prevents this from
| happening?
| 
| Also, I am wondering why in the case of the 
| 
|   foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1])
| 
| the function `fill' gets inlined into the foldr loop, but in
| the above, the lambda abstraction gets not inlined into
| $wsimpleGen.  Maybe it is because $wsimpleGen itself gets
| not inlined...
| 
| Cheers,
| Manuel
|