[GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm
GHC
ghc-devs at haskell.org
Mon Aug 11 21:43:20 UTC 2014
#9308: nofib fannkuch-redux runs perpetually with -fllvm
-------------------------------------+-------------------------------------
Reporter: jrp | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.3
(LLVM) | Keywords: fannkuch-redux
Resolution: | Architecture: x86_64 (amd64)
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: Incorrect | Related Tickets: #5567
result at runtime |
Test Case: fannkuch- |
redux |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Changes (by rwbarton):
* failure: Runtime performance bug => Incorrect result at runtime
* component: NoFib benchmark suite => Compiler (LLVM)
* os: MacOS X => Unknown/Multiple
* related: => #5567
Comment:
I can reproduce this with LLVM 3.3 on Linux x86_64. This one is a TBAA
issue. The infinite loop goes away with `-fno-llvm-tbaa` or with this
patch applied (from #9125):
{{{
diff --git a/compiler/llvmGen/LlvmCodeGen/Regs.hs
b/compiler/llvmGen/LlvmCodeGen/Regs.hs
index 0048659..d837d13 100644
--- a/compiler/llvmGen/LlvmCodeGen/Regs.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Regs.hs
@@ -101,11 +101,6 @@ stgTBAA
, (heapN, fsLit "heap", Just topN)
, (rxN, fsLit "rx", Just heapN)
, (baseN, fsLit "base", Just topN)
- -- FIX: Not 100% sure about 'others' place. Might need to be under
'heap'.
- -- OR I think the big thing is Sp is never aliased, so might want
- -- to change the hieracy to have Sp on its own branch that is never
- -- aliased (e.g never use top as a TBAA node).
- , (otherN, fsLit "other", Just topN)
]
-- | Id values
@@ -115,7 +110,7 @@ stackN = getUnique (fsLit "LlvmCodeGen.Regs.stackN")
heapN = getUnique (fsLit "LlvmCodeGen.Regs.heapN")
rxN = getUnique (fsLit "LlvmCodeGen.Regs.rxN")
baseN = getUnique (fsLit "LlvmCodeGen.Regs.baseN")
-otherN = getUnique (fsLit "LlvmCodeGen.Regs.otherN")
+otherN = topN
-- | The TBAA metadata identifier
tbaa :: LMString
}}}
The issue is Cmm code that looks like this:
{{{
/*
let go !acc = do
k <- peekElemOff xs 0
if k == 0 then f acc else flop (fromIntegral k) xs >> go
(acc+1)
*/
c7b3:
_s6xW::I64 = I64[Sp + 8];
_s6yp::I64 = %MO_UU_Conv_W8_W64(I8[_s6xW::I64]); // read from
xs via _s6xW: TBAA "other"
if (_s6yp::I64 != 0) goto c7ca; else goto c7cb;
c7ca:
I64[Sp - 8] = block_c7bd_info;
R3 = _s6xW::I64 + _s6yp::I64;
R2 = _s6xW::I64;
Sp = Sp - 8;
call $wa1_r6tm_info(R3, R2) args: 8, res: 8, upd: 8;
...
/*
flop k xs = flopp xs (xs `advancePtr` k)
where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j)
swap i j = do
a <- peek i
b <- peek j
poke j a
poke i b
*/
$wa1_r6tm_entry() // [R3, R2]
...
{offset
c6Wl:
if (R2 < R3) goto c6Ws; else goto c6Wt;
c6Ws:
_s6uQ::I64 = %MO_UU_Conv_W8_W64(I8[R3]);
I8[R3] = I8[R2]; // read from
xs via R2: TBAA "rx"
I8[R2] = %MO_UU_Conv_W64_W8(_s6uQ::I64);
R3 = R3 - 1;
R2 = R2 + 1;
call $wa1_r6tm_info(R3, R2) args: 8, res: 0, upd: 8;
}}}
"rx" and "other" are incomparable in our TBAA tree. Apparently LLVM treats
this as undefined behavior and, in this case, emits an infinite loop.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9308#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list