[commit: integer-gmp] ghc-7.2: Don't inline most integer operations (9506f95)

[Ben Lippmeier]

On 25/07/2011, at 4:27 AM, Ian Lynagh wrote:
> 
> commit 9506f95ac32c91a9fa6ce659a4474d6f85e55268
> Author: Ian Lynagh <igloo at earth.li>
> 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.