<div>
                    Hi there,
                </div>
                <div><div><br></div><div>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.</div><div>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:</div><div>(PS: the "Verifying ..." line was printed by my pass, only to show which instructions would be checked right after it)</div><div><br></div><div></div><blockquote type="cite"><div>$ opt -basicaa -load Hello.dylib -hello engine/dragon.bc -debug-only=da > /dev/null</div><div><div>[…] Verifying: "%1525 = load i32* %1524, align 4, !dbg !1371, !tbaa !693" AND  "store i32 1, i32* %1532, align 4, !dbg !1381, !tbaa !693"</div><div>    common nesting levels = 1</div><div>    maximum nesting levels = 1</div><div>    SrcPtrSCEV = @worm</div><div>    DstPtrSCEV = @worm</div><div>    using GEPs</div><div>Assertion failed: (isSCEVable(V->getType()) && "Value is not SCEVable!"), function getSCEV, file /Developer/llvm/lib/Analysis/ScalarEvolution.cpp, line 2721.</div><div>0  libLLVM-3.3svn.dylib 0x0000000105b01cee llvm::sys::PrintStackTrace(__sFILE*) + 46</div><div>1  libLLVM-3.3svn.dylib 0x0000000105b01ffb PrintStackTraceSignalHandler(void*) + 27</div><div>2  libLLVM-3.3svn.dylib 0x0000000105b02309 SignalHandler(int) + 297</div><div>3  libsystem_c.dylib      0x00007fff8bae694a _sigtramp + 26</div><div>4  libsystem_c.dylib      0x00007fff5b3d0d88 _sigtramp + 3482231896</div><div>5  libLLVM-3.3svn.dylib 0x0000000105b0202b raise + 27</div><div>6  libLLVM-3.3svn.dylib 0x0000000105b020e2 abort + 18</div><div>7  libLLVM-3.3svn.dylib 0x0000000105b020c1 __assert_rtn + 129</div><div>8  libLLVM-3.3svn.dylib 0x0000000104d570e1 llvm::ScalarEvolution::getSCEV(llvm::Value*) + 145</div><div>9  libLLVM-3.3svn.dylib 0x0000000104c3c7ac llvm::DependenceAnalysis::depends(llvm::Instruction*, llvm::Instruction*, bool) + 2076</div><div>10 Hello.dylib                0x000000010871221a llvm::Hello::countMemoryDependences() + 858</div><div>11 Hello.dylib                0x000000010872b073 llvm::Hello::initialize(llvm::Loop*) + 691</div><div>12 Hello.dylib                0x00000001087142e5 llvm::Hello::runOnLoop(llvm::Loop*, llvm::LPPassManager&) + 389</div><div>13 libLLVM-3.3svn.dylib 0x0000000104cab04d llvm::LPPassManager::runOnFunction(llvm::Function&) + 1149</div><div>14 libLLVM-3.3svn.dylib 0x000000010528c07f llvm::FPPassManager::runOnFunction(llvm::Function&) + 431</div><div>15 libLLVM-3.3svn.dylib 0x000000010528c368 llvm::FPPassManager::runOnModule(llvm::Module&) + 104</div><div>16 libLLVM-3.3svn.dylib 0x000000010528c76a llvm::MPPassManager::runOnModule(llvm::Module&) + 634</div><div>17 libLLVM-3.3svn.dylib 0x000000010528cfae llvm::PassManagerImpl::run(llvm::Module&) + 302</div><div>18 libLLVM-3.3svn.dylib 0x000000010528d251 llvm::PassManager::run(llvm::Module&) + 33</div><div>19 opt                  0x000000010483d351 main + 6593</div><div>20 libdyld.dylib        0x00007fff8e8b67e1 start + 0</div><div>Stack dump:</div><div>0.<span class="Apple-tab-span" style="white-space:pre"> </span>Program arguments: opt -basicaa -load Hello.dylib -hello engine/dragon.bc -debug-only=da </div><div>1.<span class="Apple-tab-span" style="white-space:pre">     </span>Running pass 'Function Pass Manager' on module 'engine/dragon.bc'.</div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Running pass 'Loop Pass Manager' on function '@make_dragons'</div><div>3.<span class="Apple-tab-span" style="white-space:pre">       </span>Running pass 'Hello Pass' on basic block '%1516'</div></div><div></div></blockquote><div><br></div><div>So, I have two questions: </div><div>1. What does it mean when the *PtrSCEV of a instruction has the value "@worm" in it?</div><div>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?)</div><div><br></div><div>Thanks in advance,</div><div><br></div><div>-- </div><div>Cristianno Martins</div><div>PhD Candidate in Computer Science</div><div>University of Campinas</div><div>cmartins@ic.unicamp.br</div></div>