Hi there,
I've been playing with some benchmarks for a while, but I'm stuck with a
very specific issue, that, I guess, must be some kind of bug.
Well, I wrote a pass that simply counts how many combinations of memory accesses
(only stores and loads, on a given loop) has any dependence between them.
Curiously, I didn't have any problems until I tried it out on one of the
loops in the make_dragons function (SPEC int 2006, gobmk benchmark,
engine/dragon.c), when I got the following error message:
(PS: the "Verifying ..." line was printed by my pass, only to show
which instructions would be checked right after it)
> $ opt -basicaa -load Hello.dylib -hello engine/dragon.bc -debug-only=da
> /dev/null
> […] Verifying: "%1525 = load i32* %1524, align 4, !dbg !1371, !tbaa
!693" AND "store i32 1, i32* %1532, align 4, !dbg !1381, !tbaa
!693"
> common nesting levels = 1
> maximum nesting levels = 1
> SrcPtrSCEV = @worm
> DstPtrSCEV = @worm
> using GEPs
> Assertion failed: (isSCEVable(V->getType()) && "Value is
not SCEVable!"), function getSCEV, file
/Developer/llvm/lib/Analysis/ScalarEvolution.cpp, line 2721.
> 0 libLLVM-3.3svn.dylib 0x0000000105b01cee
llvm::sys::PrintStackTrace(__sFILE*) + 46
> 1 libLLVM-3.3svn.dylib 0x0000000105b01ffb
PrintStackTraceSignalHandler(void*) + 27
> 2 libLLVM-3.3svn.dylib 0x0000000105b02309 SignalHandler(int) + 297
> 3 libsystem_c.dylib 0x00007fff8bae694a _sigtramp + 26
> 4 libsystem_c.dylib 0x00007fff5b3d0d88 _sigtramp + 3482231896
> 5 libLLVM-3.3svn.dylib 0x0000000105b0202b raise + 27
> 6 libLLVM-3.3svn.dylib 0x0000000105b020e2 abort + 18
> 7 libLLVM-3.3svn.dylib 0x0000000105b020c1 __assert_rtn + 129
> 8 libLLVM-3.3svn.dylib 0x0000000104d570e1
llvm::ScalarEvolution::getSCEV(llvm::Value*) + 145
> 9 libLLVM-3.3svn.dylib 0x0000000104c3c7ac
llvm::DependenceAnalysis::depends(llvm::Instruction*, llvm::Instruction*, bool)
+ 2076
> 10 Hello.dylib 0x000000010871221a
llvm::Hello::countMemoryDependences() + 858
> 11 Hello.dylib 0x000000010872b073
llvm::Hello::initialize(llvm::Loop*) + 691
> 12 Hello.dylib 0x00000001087142e5
llvm::Hello::runOnLoop(llvm::Loop*, llvm::LPPassManager&) + 389
> 13 libLLVM-3.3svn.dylib 0x0000000104cab04d
llvm::LPPassManager::runOnFunction(llvm::Function&) + 1149
> 14 libLLVM-3.3svn.dylib 0x000000010528c07f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 431
> 15 libLLVM-3.3svn.dylib 0x000000010528c368
llvm::FPPassManager::runOnModule(llvm::Module&) + 104
> 16 libLLVM-3.3svn.dylib 0x000000010528c76a
llvm::MPPassManager::runOnModule(llvm::Module&) + 634
> 17 libLLVM-3.3svn.dylib 0x000000010528cfae
llvm::PassManagerImpl::run(llvm::Module&) + 302
> 18 libLLVM-3.3svn.dylib 0x000000010528d251
llvm::PassManager::run(llvm::Module&) + 33
> 19 opt 0x000000010483d351 main + 6593
> 20 libdyld.dylib 0x00007fff8e8b67e1 start + 0
> Stack dump:
> 0. Program arguments: opt -basicaa -load Hello.dylib -hello
engine/dragon.bc -debug-only=da
> 1. Running pass 'Function Pass Manager' on module
'engine/dragon.bc'.
> 2. Running pass 'Loop Pass Manager' on function
'@make_dragons'
> 3. Running pass 'Hello Pass' on basic block '%1516'
>
>
So, I have two questions:
1. What does it mean when the *PtrSCEV of a instruction has the value
"@worm" in it?
2. Is this the correct behavior, given the two instructions been handled by the
DependenceAnalysis::depends function? If so, how can I avoid having this
assertion failed? (or how can I identify precisely when this could happen and
avoid by myself calling depends?)
Thanks in advance,
--
Cristianno Martins
PhD Candidate in Computer Science
University of Campinas
cmartins at ic.unicamp.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130411/e7769418/attachment.html>
