Compiler optimizations questions for ghc 6.10...

[Max Bolingbroke]

2009/2/17 Tyson Whitehead <twhitehead at gmail.com>:
> (compiled with ghc 6.10 with options -O2 -ddump-simpl)
>
> I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at
> the bottom of this email as that is the only place it is ever referenced.

The relevant GHC code is SimplUtils.preInlineUnconditionally. It looks
like it dosen't get inlined for two reasons:
1) It's not a manifest lambda (it's an application) so inlining inside
another lambda would change the number of times the FVs of lvl_s1mF
might occur
2) I'm not sure if the use-context is considered interesting by GHC
because the application of the function might be hidden by the cast.
Not sure about this one.

So it looks like the problem stems from digit_s1l3 having arity 1
rather than arity 3. You could try and force it into a higher arity
somehow, but I can't say exactly how you might do that without seeing
the rest of the Core (and in particular the part under the first
lambda in the definition of digit).

In general, the -ddump-inlinings flag is useful for working out why
something wasn't inlined - but it wouldn't have helped you in this
case, because it only dumps information about inlining at call sites,
and you actually want an unconditional inlining to occur.

> It also seems the extra levels of indirection are defeating the strictness
> analyzer on eta_s1CN in a_s1Gv as all code branches either directly force it
> or ultimately pass it to digit_s1l3 as in the included branch.
>
> Also, why isn't digit_s1l3 optimized to take its first parameter unboxed?  It
> is strict in its first argument, and grepping the core shows that it is only
> ever used like in lvl_s1mF (i.e., passed things like lvl_s1mG).

Yeah, that's weird. I don't know the answer to this. Have you actually
got to the worker-wrapper stage at the point you copied this core?

> Thanks!  -Tyson
>
> PS:  Is there any way to get better control over the loop breaker choice?  For
> a slightly simpler digit function, it is not chosen, and great code is
> produced.  I've tried using INLINE on digit, but that seems to result in the
> monad bind operator not being inlined, which produces even worse code.

GHC won't inline inside functions marked with INLINE pragmas, for
various very good reasons. I don't know how you could change the loop
breaker given the current state of technology, but SPJ has a patch for
GHC in the works that revamps the treatment of INLINE pragmas and
which should (if my understanding of his patch is correct) solve the
issue with >>= not being inlined within an inlineable digit.

Sorry I can't be more helpful. It's possible I could make some more
concrete suggestions if you posted the complete code somewhere.
Max