[GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)

[GHC]

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into
<<loop>>)
-------------------------------------+-------------------------------------
        Reporter:  exio4             |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 I took a look at the generated STG for par2.hs before and after the
 cardinality analysis commit. Before, there are no `\s` thunks at all.
 After, there are two. One is in
 {{{
 Main.main_go [Occ=LoopBreaker]
   :: [[GHC.Types.Char]] -> [GHC.Types.Char]
 [GblId,
  Arity=1,
  Caf=NoCafRefs,
  Str=DmdType <S,U>,
  Unf=OtherCon []] =
     \r srt:SRT:[] [ds_s1nu]
         case ds_s1nu of _ {
           [] -> [] [];
           : y_s1ny [Occ=Once] ys_s1nz [Occ=Once] ->
               let {
                 sat_s1pj [Occ=Once, Dmd=<L,1*U>] :: [GHC.Types.Char]
                 [LclId, Str=DmdType] =
                     \s srt:SRT:[] [] Main.main_go ys_s1nz;
               } in  GHC.Base.++ y_s1ny sat_s1pj;
         };
 }}}
 This comes from the Core
 {{{
 Main.main_go [Occ=LoopBreaker]
   :: [[GHC.Types.Char]] -> [GHC.Types.Char]
 [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,U>]
 Main.main_go =
   \ (ds_XrA :: [[GHC.Types.Char]]) ->
     case ds_XrA of _ {
       [] -> GHC.Types.[] @ GHC.Types.Char;
       : y_arg ys_arh ->
         GHC.Base.++ @ GHC.Types.Char y_arg (Main.main_go ys_arh)
     }
 }}}
 which presumably comes from the use of `concat` in `layer`. This happens
 even when I build the program with `-fkill-absence -fkill-one-shot`. Could
 that be because base was built with cardinality analysis enabled? I don't
 entirely see how, but I can try rebuilding the libraries with `-fkill-
 absence -fkill-one-shot`.

 Anyways I guess the main question, which I'm not sure how to answer, is
 whether the fact that this thunk is marked as single-entry is correct.

 The other single-entry thunk is, I think, very similar and arises from
 `concatMap`:
 {{{
 {- note
 $wlayer_r1m6
   :: (GHC.Types.Char -> GHC.Base.String)
      -> GHC.Prim.Char# -> GHC.Base.String
 [GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []]
 w3_r1ma :: GHC.Types.Char -> GHC.Base.String
 [GblId, Arity=1, Str=DmdType, Unf=OtherCon []]
 -}
 Main.main_go2 [Occ=LoopBreaker]
   :: [GHC.Types.Char] -> [GHC.Types.Char]
 [GblId, Arity=1, Str=DmdType <S,1*U>, Unf=OtherCon []] =
     \r srt:SRT:[(r8, Main.main_go2), (r1m6, $wlayer_r1m6),
                 (r1ma, w3_r1ma)] [ds_s1oh]
         case ds_s1oh of _ {
           [] -> [] [];
           : y_s1ol [Occ=Once!] ys_s1oq [Occ=Once] ->
               case y_s1ol of _ {
                 GHC.Types.C# ww1_s1oo [Occ=Once] ->
                     let {
                       sat_s1pv [Occ=Once, Dmd=<L,1*U>] :: [GHC.Types.Char]
                       [LclId, Str=DmdType] =
                           \s srt:SRT:[(r8, Main.main_go2)] []
 Main.main_go2 ys_s1oq;
                     } in
                       case $wlayer_r1m6 w3_r1ma ww1_s1oo of sat_s1pu {
                         __DEFAULT -> GHC.Base.++ sat_s1pu sat_s1pv;
                       };
               };
         };
 }}}

 I'm going to see what happens when I inline the definitions of `concat`
 and `concatMap` into this module.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10414#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler