[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