So we either need to * inline floatFromInteger, or * need a RULE for floatFromInteger
If the former is big, the latter should do fine, right? That's what we are doing for other Integer operations. 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
