[GHC] #5681: par# and spark# call newSpark differently, confuses LLVM backend

GHC cvs-ghc at haskell.org
Mon Dec 5 16:41:19 CET 2011


#5681: par# and spark# call newSpark differently, confuses LLVM backend
---------------------------------+------------------------------------------
    Reporter:  scpmw             |       Owner:  dterei                   
        Type:  bug               |      Status:  new                      
    Priority:  normal            |   Component:  Compiler (LLVM)          
     Version:  7.2.1             |    Keywords:                           
    Testcase:                    |   Blockedby:                           
          Os:  Unknown/Multiple  |    Blocking:                           
Architecture:  Unknown/Multiple  |     Failure:  GHC rejects valid program
---------------------------------+------------------------------------------
 If `par#` and `spark#` are being used in the same compilation unit, say
 like

 {{{
   case spark# (work 2) realWorld# of
     (# _, _ #) -> case par# (work 1) of
         _ -> return ()
 }}}

 The LLVM backend generates code like follows:

 {{{
     call ccc void (i8*,i8*)* @newSpark( i8* %lnnX, i8* %lnnZ ) nounwind
 [...]
     %lno7 = call ccc void (i8*,i8*)* @newSpark( i8* %lno4, i8* %lno6 )
 nounwind
 }}}

 So both call `newSpark` under the hood - but inconsistently. The first
 call expects no returned value, while the second does. As the first seen
 call doesn't have a returned value, the backend concludes that the
 function's type must be `void (i8*,i8*) *`, which make `opt` choke on the
 second usage:

 {{{
 opt: /tmp/ghc23150_0/ghc23150_0.ll:845:1: error: instructions returning
 void cannot have a name
 %lno7 = call ccc void (i8*,i8*)* @newSpark( i8* %lno4, i8* %lno6 )
 nounwind
 ^
 }}}

 The underlying reason is in code generation: It doesn't always ask for the
 return value of `newSpark`. So one way to fix this is to just always get
 the return value - but simply discard it if it's not needed. Patch
 attached.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5681>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler



More information about the Glasgow-haskell-bugs mailing list