[GHC] #7109: Inlining depends on datatype size, even with INLINE pragmas

[GHC]

#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