Opened 7 years ago

Last modified 3 years ago

#7283 new feature request

Specialise INLINE functions

Reported by: rl Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.7
Keywords: Inlining Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Quick summary: At the moment, INLINE means inline a function if it is fully applied and don't use its unfolding otherwise. I think we might want to change this to INLINE a function if it is fully applied and treat it as to INLINABLE otherwise.

Here is a small example:

module T where

f :: Num a => a -> a
{-# INLINE [1] f #-}
f = \x -> x+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1

g :: Num a => a -> a
{-# INLINE [1] g #-}
g x = x+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2

h :: Num a => a -> a
{-# INLINABLE [1] h #-}
h x = x+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3

apply :: (a -> b) -> a -> b
{-# NOINLINE apply #-}
apply f x = f x
module U where

import T

ff :: Int -> Int -> Int
ff x y = apply f x + apply f y

gg :: Int -> Int -> Int
gg x y = apply g x + apply g y

hh :: Int -> Int -> Int
hh x y = apply h x + apply h y

With -O2 -fno-cse (CSE does optimise this example but doesn't solve the problem of intermediate code bloat), GHC produces the following:

  • The RHS of f is duplicated since it is inlined twice - bad.
  • g is neither inlined nor specialised since it isn't fully applied - bad.
  • h is specialised but its RHS isn't duplicated - good.

But of course, h isn't guaranteed to be inlined even if it is fully applied which, in the real-world examples I have in mind, is bad.

I think INLINE [n] f should mean that:

  1. f will always be inlined if it is fully applied,
  2. f will be specialised when possible,
  3. specialisations of f will also be INLINE [n].

I don't think it's possible to achieve this effect at the moment. If we treated INLINE [n] as INLINABLE [n] until the function is fully applied, we would get exactly this, though, except for 3 which probably isn't too hard to implement.

Now, if I understand correctly, INLINABLE also means that GHC is free to inline the function if it wants but the function isn't treated as cheap. I think it would be fine if we did this for unsaturated INLINE functions rather than not inlining them under any circumstances. The original motivation for only inlining when fully applied was code bloat in DPH. But IIRC that only happened because INLINE functions were always cheap and so GHC was very keen to inline them even when they weren't saturated which wouldn't be the case with my proposal. We would have to check how this affects DPH and related libraries, though.

Change History (8)

comment:1 Changed 7 years ago by simonpj

difficulty: Unknown

Roman, your proposal sounds very plausible to me.

(I don't understand your last paragraph though.)

comment:2 Changed 7 years ago by rl

I'll try to rephrase the last paragraph. The problem is that this change will make GHC inline more since it will now be able (but not keen) to inline INLINE functions even if they aren't applied to enough arguments. The original reason for making INLINE respect arity was code bloat so we should be careful not to reintroduce this problem with this change. However, if INLINE functions that are not applied to enough arguments are treated exactly as INLINABLE then GHC won't try extra hard to inline them so perhaps we will be ok. This is different to what we had before the arity restriction on INLINE - back then, GHC would try extra hard to inline regardless of the number of arguments. So while we will inline more under my proposal, it will (hopefully) still be substantially less than in the bad old days.

comment:3 Changed 6 years ago by igloo

Milestone: 7.8.1

comment:4 Changed 5 years ago by thoughtpolice

Milestone: 7.8.37.10.1

Moving to 7.10.1

comment:5 Changed 5 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:6 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:7 Changed 4 years ago by thomie

Milestone: 8.0.1

comment:8 Changed 3 years ago by mpickering

Keywords: Inlining added
Note: See TracTickets for help on using tickets.