Specialise INLINE functions
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 fnocse (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 realworld examples I have in mind, is bad.
I think INLINE [n] f
should mean that:

f
will always be inlined if it is fully applied, 
f
will be specialised when possible,  specialisations of
f
will also beINLINE [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.
Trac metadata
Trac field  Value 

Version  7.7 
Type  FeatureRequest 
TypeOfFailure  OtherFailure 
Priority  normal 
Resolution  Unresolved 
Component  Compiler 
Test case  
Differential revisions  
BlockedBy  
Related  
Blocking  
CC  
Operating system  
Architecture 