#7109: Inlining depends on datatype size, even with INLINE pragmas -------------------------------------+------------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:4 thomie]:

Pedro: is that sufficiently small, or do you still think there is a bug somewhere?

I think there's still a problem. Let's look at the code for `Bug2.hs`, which simply has one fewer constructor: {{{ $fGEqLogic_$cgeq $fGEqLogic_$cgeq = \ x_aYs y_aYt -> case x_aYs of _ { T -> case y_aYt of _ { T -> True; F -> False; Not g1_aBc_a1kH -> False }; F -> case y_aYt of _ { __DEFAULT -> False; F -> True }; Not g1_aBc_a1kH -> case y_aYt of _ { __DEFAULT -> False; Not g1_aBc1_X1mN -> $fGEqLogic_$cgeq g1_aBc_a1kH g1_aBc1_X1mN } } }}} This looks good. No casts, no `L`/`R`, just a perfectly specialised function. In contrast, `Bug3` (which simply adds one constructor) has generic representation leftovers and casts all over the place. It still feels like something is behaving significantly different just because the datatype got slightly bigger, and I don't know how to tell GHC that it shouldn't be afraid of inlining stuff just because the terms are bigger. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7109#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler