Loop unrolling + fusion ?

[Claus Reinke]

> The implementation I'm thinking of is basically trivial. You just add
> the information gathered from the pragmas onto the Ids, then have a
> dedicated core pass that looks at the pragmas and does it's
> worker/wrapper thing. The technology to do peeling/unrolling is
> trivial and there already examples in the codebase (in case liberation
> and SAT). If someone can spec out what they actually want and GHC HQ
> give it the thumbs up I would be happy to do the grunt work on
> implementing this feature.

Yes, please!-)

My preferred spec would be roughly

{-# NOINLINE f #-}
    as now

{-# INLINE f #-} 
    works as now, which is for non-recursive f only (might in future
    be taken as go-ahead for analysis-based recursion unfolding)

{-# INLINE f PEEL n #-}
    inline calls *into* recursive f (called loop peeling for loops)
 
{-# INLINE f UNROLL m #-}
    inline recursive calls to f *inside* f (called loop unrolling for loops)

{-# INLINE f PEEL n UNROLL m #-}
    combine the previous two

    The numeric parameters are to be interpreted as if each call to
    f was annotated with both PEEL and UNROLL limits, to be
    decreased as appropriate for every PEEL or UNROLL action.
    Peeling and unrolling stop when the respective count annotation
    has reached 0. Note that mutual recursion is the domain of PEEL,
    while UNROLL only applies to direct recursion.

    {-# INLINE f PEEL n #-}, for n>0, corresponds to worker/
    wrapper transforms (previously done manually) + inline wrapper,
    and should therefore also be taken as a hint for the compiler to 
    try the static argument transformation for f (the "worker").

    Non-supporting implementations should treat these as INLINE
    pragmas (same warning/ignore or automatic unfold behaviour).

About the pragma name: as far as I can tell, Hugs simply ignores
INLINE pragmas, no matter what they say, other implementations
could just ignore the PEEL/UNROLL part (possibly with a warning)
- do any of them support INLINE on recursive definitions?

The only problem is that GHC itself fails with a parse error, which
would lead to version issues (perhaps GHC should have allowed
for additional information to otherwise syntactically complete pragmas,
or warnings instead of errors, but that hitch is out in the wild now).

Having separate PEEL/UNROLL pragmas would make ignoring
the default action, but would clutter the pragma name space as well
as the source code; it also wouldn't make explicit that we are indeed 
refining the INLINE pragma for the case of recursive functions (which 
GHC currently ignores or complains about), by detailing how we want 
the recursive definition to be inlined.

Since we are talking about a refinement of the INLINE pragma, we
also need to look at that pragma's existing subtleties:-(

- no functions inlined into f: should be subject to override by
    INLINE pragmas (even for the non-recursive case?)
- no float-in/float-out/cse: ??
- no worker/wrapper transform in strictness analyser: we do get the 
    same effect from INLINE PEEL, so this should be okay, right?
- loop breakers: PEEL/UNROLL have their own limits, creating
    an intrinsic loop breaker when the counters run out

Is that sufficient?
Claus