On 5/2/12 7:16 AM, Simon Marlow wrote:
I would like the folds to be INLINABLE. Rationale:
- The 0.8% figure is really plucked out of thin air, it depends entirely on how many times we call fold.
- Getting a complete copy of fold each time you call it is overkill.
- INLINABLE puts the user in control of the performance/size tradeoff; with INLINE the user has no control, they always get a copy (well, they could write a NOINLINE wrapper, but that's horrible).
What exactly are the semantics of INLINABLE again? I know it means that it's like a constructor in that it's considered cheap to reevaluate, but how does that play into the whole inlining/rules/fusion/cse infrastructure? I know one thing I run into a lot, especially with folds but also with other generic functions, is that what I really want is type class specialization. That is, at compile time inline the function enough to make the type class parameters static so that the methods can be inlined back into the generic function; and then at runtime do type-based dispatch to the specialized versions just like if you were looking up the instance record or doing SPECIALIZE lookup. The goal being to remove the indirect calls in inner loops, but in a particularly restricted way since instances are known at compile time and therefore code bloat will be limited (unlike, say, function or record arguments). Since that's one of the big goals that people use the INLINE hammer for, I wonder if it would be sensible to have a pragma which specifically offers those semantics. It doesn't quite solve the fold issue since many folds use ad-hoc arguments, but it may help reduce code bloat elsewhere. -- Live well, ~wren