Re: [GHC] #16038: Simplifier incorrectly breaks recursive groups

19 Dec 2018

      #16038: Simplifier incorrectly breaks recursive groups
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  osa1
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:
       Component:  Compiler          |              Version:  8.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 If I add print statements to print input and output of `occurAnalysePgm`,
 and
 also force it to do glomming always, I see that at one point this is the
 input:

 {{{
 Rec {
 $fEqHsExpr
 $fEqHsExpr
   = \ @ id_a27U $dEq_a27V ->
       C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V)

 $c/=_a287
 $c/=_a287
   = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 ->
       case $c==_a27X $dEq_a27V eta_B2 eta_B1 of {
         False -> True;
         True -> False
       }

 $c==_a27X
 $c==_a27X
   = \ @ id_a27U $dEq_a27V ->
       let {
         $dEq_a283
         $dEq_a283 = $fEqHsExpr $dEq_a27V } in
       let {
         $dEq_a281
         $dEq_a281 = $fEqHsOverLit $dEq_a27V } in
       \ ds_d2jB ds_d2jC ->
         join {
           fail_d2jD
           fail_d2jD _ = False } in
         case ds_d2jB of {
           HsOverLit a1_a27Q ->
             case ds_d2jC of {
               HsOverLit b1_a27R ->
                 let {
                   $dEq1_a2k1
                   $dEq1_a2k1 = noinline $fxEqHsExpr $dEq_a27V } in
                 case a1_a27Q of { OverLit a1_a2k8 ->
                 case b1_a27R of { OverLit b1_a2kc ->
                 == $dEq1_a2k1 a1_a2k8 b1_a2kc
                 }
                 };
               HsBracketOut ipv_s2kg -> False
             };
           HsBracketOut a1_a27S ->
             case ds_d2jC of {
               HsOverLit ipv_s2kj -> False;
               HsBracketOut b1_a27T -> $c==_a27X $dEq_a27V a1_a27S b1_a27T
             }
         }
 end Rec }

 $fxEqHsExpr
 $fxEqHsExpr = $fEqHsExpr

 ...
 }}}

 This is already incorrect (`$fxEqHsExpr` should be in the recursive
 group),
 but what I don't understand is even after flattening the whole program and
 doing
 occurance analysis we end up with incorrect recursive group:

 {{{
 Rec {
 $c==_a27X
 $c==_a27X
   = \ @ id_a27U $dEq_a27V ds_d2jB ds_d2jC ->
       case ds_d2jB of {
         HsOverLit a1_a27Q ->
           case ds_d2jC of {
             HsOverLit b1_a27R ->
               let {
                 $dEq1_a2k1
                 $dEq1_a2k1 = noinline $fxEqHsExpr $dEq_a27V } in
               case a1_a27Q of { OverLit a1_a2k8 ->
               case b1_a27R of { OverLit b1_a2kc ->
               == $dEq1_a2k1 a1_a2k8 b1_a2kc
               }
               };
             HsBracketOut _ -> False
           };
         HsBracketOut a1_a27S ->
           case ds_d2jC of {
             HsOverLit _ -> False;
             HsBracketOut b1_a27T -> $c==_a27X $dEq_a27V a1_a27S b1_a27T
           }
       }
 end Rec }

 $c/=_a287
 $c/=_a287
   = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 ->
       case $c==_a27X $dEq_a27V eta_B2 eta_B1 of {
         False -> True;
         True -> False
       }

 $fEqHsExpr
 $fEqHsExpr
   = \ @ id_a27U $dEq_a27V ->
       C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V)

 $fxEqHsExpr
 $fxEqHsExpr = $fEqHsExpr
 }}}

 Perhaps this is a bug in the occurance analysis? I wonder if the
 `noinline` is
 relevant somehow ...

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16038#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler