2009/2/17 Tyson Whitehead <twhiteh...@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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
