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
