I was trying to see what kind of informations I can get on dependence/alias analysis from the trunk llvm, and stumbled upon two potencial problems. First of all, the most recent documentation I could find online suggests the use of options not available on the code (like enabling globalsmodref-aa, or count-aa, for example). Is there a more recent one, or is just the documentation not being updated?
Second, after trying “opt --help” and scanning for everything that remotely resembled alias or dependency analysis, I ended up trying to run opt over part of the code of bzip2 from SPEC 2006, but unfortunately an assertion fail prevents it from finishing the analysis:
Assertion failed: (dep.isUnknown() && “unexpected dependence type”), function getInstTypePair, file /Developer/llvm/lib/Analysis/MemDepPrinter.cpp, line 70.
Program arguments: /Developer/llvm/build/bin/opt -aa -aa-eval -basicaa -cfl-aa -external-aa -globals-aa -objc-arc-aa -print-alias-sets -scev-aa -scoped-noalias -tbaa -da -memdep -print-memdeps build_base_yosemite.0000/blocksort.bc -debug-pass=Structure -disable-output -S
Running pass ‘Function Pass Manager’ on module ‘build_base_yosemite.0000/blocksort.bc’.
Running pass ‘Print MemDeps of function’ on function ‘@BZ2_blockSort’
Illegal instruction: 4
I was kinda curious about which instruction was causing this assertion to be thrown, and I added a print to the MemDepPrinter class to see that the instruction was actually an llvm intrinsic:
Instruction: call void @llvm.memset.p0i8.i32(i8* %bigDone152.i, i8 0, i32 256, i32 1, i1 false) #6
So, my question is: is this the expected behavior for MemDepPrinter? Is there anything I can do to avoid failing this assertion?
Thanks in advance,