Hi,
I am trying to use the poolallocator. More specific, I am trying to play around with the pointer compression pass. Though, I get assertion failures for the pass dependencies.
This is when it in PointerCompress::getAnalysisUsage tries to register the the BU pass as required. I.e. when AU.addRequired<CompleteBUDataStructures>(); is called.
$ opt -f -load ~/Projects/llvmstuff/opt/poolalloc/lib/libpoolalloc.dylib -raiseallocs -poolalloc-passing-all-pools -pointercompress llist-noopt.bc -o llist-dp.bc
Assertion failed: ((P->getPotentialPassManagerType() < RequiredPass- >getPotentialPassManagerType()) && "Unable to handle Pass that requires lower level Analysis pass"), function addLowerLevelRequiredPass, file ~/Projects/llvmstuff/llvm/lib/VMCore/PassManager.cpp, line 1418.
Any ideas what is going wrong here?
/Mattias
Hi all,
I too am getting this error for x86_64 when I am trying to use the
Data Structure Analysis ...I svn upped both the llvm main branch and
the poolalloc today in the morning and recompiled everything from
scratch :
$ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so
-ds-aa < o.bc
opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual
void llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*): Assertion `(P->getPotentialPassManagerType() <
RequiredPass->getPotentialPassManagerType()) && "Unable to handle Pass
that requires lower level Analysis pass"' failed.
0 opt 0x0000000000a3fcd0
1 opt 0x0000000000a40024
2 libc.so.6 0x00007f9fc318a100
3 libc.so.6 0x00007f9fc318a095 gsignal + 53
4 libc.so.6 0x00007f9fc318baf0 abort + 272
5 libc.so.6 0x00007f9fc31832df __assert_fail + 239
6 opt 0x00000000009caeac
llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*) + 252
7 opt 0x00000000009cbe53 llvm::PMDataManager::add(llvm::Pass*,
bool) + 899
8 opt 0x00000000009cc296
llvm::ModulePass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType) + 132
9 opt 0x00000000009d5ff9
llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*) + 227
10 opt 0x00000000009cad7e
llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 500
11 opt 0x00000000009d6118 llvm::PassManagerImpl::add(llvm::Pass*) + 36
12 opt 0x00000000009cada7 llvm::PassManager::add(llvm::Pass*) + 33
13 opt 0x00000000006e5cd3
14 opt 0x00000000006e7a6d main + 3237
15 libc.so.6 0x00007f9fc31761c4 __libc_start_main + 244
16 opt 0x00000000006d7c19 __gxx_personality_v0 + 721
Aborted
Is there something that I am missing on the command line ? Does anyone
use DSA actively now ?
Thanks for your time.
- Prakash
Dear Prakash,
Yes, DSA is still in active use, although nobody else uses the -ds-aa pass as far as I know.
I tried the below sample (although ds-aa should be in libLLVMDataStructure.so and not libpoolalloc.so), and I get the same error. I've seen similar problems with other passes in our work here. My guess is that -ds-aa is requiring two passes that claim to invalidate each other; this causes a circular dependency that the pass manager cannot resolve.
I'm busy with another task this week, but if I find time, I might be able to investigate the problem and devise a solution. If you want to try fixing it in the meantime, here's what I'd suggest doing:
1) Look at all the DSA passes required by -ds-aa.
2) Change those passes so that they clone the DSGraphs of the DSA passes upon which they depend. To do this, look for calls to init() and change the second parameter from false to true.
3) Change the dependencies in the pass's getAnalysisUsage() method so that they preserve all passes (i.e. AU.setPreservedAll()).
Note that this will greatly increase memory usage, but it will allow each DSA pass to remain valid even when later DSA passes are run.
-- John T.
Dear Prakash,
I believe I've fixed the problem you were having with ds-aa. Please
update your poolalloc tree, recompile, and let me know if it works.
-- John T.
Criswell, John T wrote:
Hi John,
Thanks for the fix! It is working properly now 
:
$ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libLLVMDataStructure.so
-stats -ds-aa -ipconstprop < prog.bc
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.