Ian: pls give Ben a heads-up when this is done, so he can re-run his 
performance tests.
Also on the MacOS side, Manuel thinks we we'll need another fully release 
candidate, so that Mac folk can test the release.

Simon

| -----Original Message-----
| From: Simon Peyton-Jones
| Sent: 02 August 2011 11:33
| To: 'Ben Lippmeier'; Ian Lynagh
| Cc: [email protected] list; Roman Leshchinskiy; Manuel M T Chakravarty
| Subject: RE: [commit: integer-gmp] ghc-7.2: Don't inline most integer 
operations
| (9506f95)
| 
| We decided to solve this by removing the NOINLINE stuff from the 7.2 branch, 
rather
| than by merging all the rewrite rules. We have more to do on the Integer 
front;
| #5284, #5152.  Ian has the token on all of this.
| 
| Simon
| 
| | -----Original Message-----
| | From: Ben Lippmeier [mailto:[email protected]]
| | Sent: 01 August 2011 09:01
| | To: Ian Lynagh
| | Cc: [email protected] list; Roman Leshchinskiy; Manuel M T Chakravarty; 
Simon
| | Peyton-Jones
| | Subject: Re: [commit: integer-gmp] ghc-7.2: Don't inline most integer 
operations
| | (9506f95)
| |
| |
| | On 25/07/2011, at 4:27 AM, Ian Lynagh wrote:
| | >
| | > commit 9506f95ac32c91a9fa6ce659a4474d6f85e55268
| | > Author: Ian Lynagh <[email protected]>
| | > Date:   Sat Jul 23 17:56:40 2011 +0100
| | >
| | >    Don't inline most integer operations
| | >
| | >    We get lots of code, and the simplifier generally can't do much with
| | >    it. We'll instead use builtin rules to do constant folding where
| | >    possible.
| |
| |
| | This patch completely breaks Repa and DPH programs. More than 6000% 
slowdown in
| some
| | cases. The problem appears to be that constants in source programs are 
compiled via
| | the Integer library, and if we have applications of floatFromInteger lying 
around
| | then other things don't get inlined.
| |
| | Here is some code from the final stage of the simplifier when compiling the 
Repa
| | Sobel example:
| |
| |
| | lvl4_r7Zh :: GHC.Integer.Type.Integer
| | [GblId, Caf=NoCafRefs]
| | lvl4_r7Zh = GHC.Integer.Type.S# 0
| |
| |
| | lvl5_r7Zi :: Data.Array.Repa.Stencil.Base.Stencil Data.Array.Repa.Index.DIM2
| | GHC.Types.Float
| | [GblId, Str=DmdType]
| | lvl5_r7Zi =
| |   let { __DEFAULT ~ wild_a1NR <- GHC.Integer.Type.floatFromInteger 
lvl4_r7Zh } in
| |   Data.Array.Repa.Stencil.Base.StencilStatic
| |     @ Data.Array.Repa.Index.DIM2 @ GHC.Types.Float lvl2_r7Zf (GHC.Types.F#
| wild_a1NR)
| | lvl3_r7Zg
| |
| |
| | Solver.gradientX [InlPrag=NOINLINE] :: Solver.Image -> Solver.Image
| | [GblId, Arity=1, Str=DmdType U(S(U(U()U(A))U(A))S)]
| | Solver.gradientX =
| |   \ (img_apv :: Solver.Image) ->
| |   ...
| |      ((\ (s_a1A8 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
| |       let { __DEFAULT ~ s'_a1A9 <- GHC.Prim.noDuplicate# s_a1A8 } in
| |       let { Data.Array.Repa.Stencil.Base.StencilStatic sExtent_a1Oy 
zero_a1Oz
| | load_a1OA ~ wild4_a1Ou <- lvl5_r7Zi } in
| |       let { Data.Array.Repa.Index.:. ds5_s3sG sWidth_s3sH ~ _ <- 
sExtent_a1Oy } in
| |       let { Data.Array.Repa.Index.:. ds1_a1SG sHeight_a1SH ~ _ <- ds5_s3sG 
} in
| |       let { GHC.Types.I# ww_a2E9 ~ _ <- sHeight_a1SH } in
| |       let { __DEFAULT ~ ww1_a2Eh <- GHC.Base.divInt# ww_a2E9 2 } in
| |       let { GHC.Types.I# ww2_X2FJ ~ _ <- sWidth_s3sH } in
| |       let { __DEFAULT ~ ww3_X2Fa <- GHC.Base.divInt# ww2_X2FJ 2 } in
| |       ...
| |
| |
| | The problem is that lvl5_r7Zi isn't being inlined anymore, which in turn 
means the
| | constant zero_a1Oz and function bound to load_a1OA isn't being inlined 
either. This
| | completely breaks follow-on fusion. Note that the lvl5_r7Zi binding itself 
was
| lifted
| | out by the simplifier, so I can't attach an INLINE pragma to it to force it 
back
| in.
| |
| | There is only that single use of lvl5_r7Zi in the program, and I compile 
Repa
| | programs with the "-funfolding-use-threshold100 
-funfolding-keeness-factor100"
| | sledgehammer, so I don't know why it's not being inlined.
| |
| | When I remove all the NOINLINEs from integer-gmp:GHC.Integer.Type it works 
again.
| |
| |
| | Ben.
| |
| |
| |


_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to