I am writing an interprocedural compiler pass. Because the passneeds information from a FunctionPass, e.g., the post-dominance frontier (PDF), and because a ModulePass is not permitted to require a FunctionPass, I am forced to make my pass a FunctionPass and do majority of its work in the doFinalization() method.
When I run "opt -mypass -verify -o code2.bc code1.bc" I get no complaints. However, if I then try run "opt -simplifycfg -verify -o code3.bc code2.bc," I get the assertion failure below. If thought that the verify option should have made sure that bytecode written to code2.bc was correct. Am I incorrect?
opt: Reader.cpp:1978: llvm::Value* llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion `(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) || !hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"' failed.
opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
[0x70f420]
/lib/libc.so.6(abort+0x101)[0x4cab64f1]
/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned int)+0x1b31)[0x856e825]
opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*, std::allocator<llvm::BytecodeReader::ValueList*> >&, std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&, bool)+0x147)[0x856e985]
opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
opt((anonymous namespace)::BytecodeFileReader::read(std::basic_string<char, std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
opt(llvm::getBytecodeModuleProvider(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, llvm::BytecodeHandler*)+0x93)[0x855b60b]
opt(llvm::ParseBytecodeFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*)+0x20)[0x855b88e]
opt(main+0x7e)[0x8378c90]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
opt(__gxx_personality_v0+0x149)[0x836bac1]
Abort
Regards,
Ryan
I am writing an interprocedural compiler pass. Because the passneeds
information from a FunctionPass, e.g., the post-dominance frontier
(PDF), and because a ModulePass is not permitted to require a
FunctionPass, I am forced to make my pass a FunctionPass and do majority
of its work in the doFinalization() method.
ok
When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
complaints. However, if I then try run "opt -simplifycfg -verify -o
code3.bc code2.bc," I get the assertion failure below. If thought that
the verify option should have made sure that bytecode written to
code2.bc was correct. Am I incorrect?
Yes. the passmanager runs the passes in roughly this order:
1. doinitialization for mypass and verify
2. runOnModule for mypass
3. verifier::runOnFunction for each function
4. dofinalization for mypass
5. dofinalization for verify
Because you'd doing your xform in #4, but verifier checks the code at #3, you lose 
However, there is hope! Just call "llvm/Analysis/Verifier.h" -> verifyModule or verifyFunction explicitly in your pass.
-Chris
opt: Reader.cpp:1978: llvm::Value*
llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
`(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
!hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
failed.
opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
[0x70f420]
/lib/libc.so.6(abort+0x101)[0x4cab64f1]
/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
int)+0x1b31)[0x856e825]
opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
std::allocator<llvm::BytecodeReader::ValueList*> >&,
std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
bool)+0x147)[0x856e985]
opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
int, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
opt((anonymous
namespace)::BytecodeFileReader::read(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
llvm::BytecodeHandler*)+0x93)[0x855b60b]
opt(llvm::ParseBytecodeFile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char>
>*)+0x20)[0x855b88e]
opt(main+0x7e)[0x8378c90]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
opt(__gxx_personality_v0+0x149)[0x836bac1]
Abort
Regards,
Ryan
-Chris
I followed what you said and called verifyModule() with the AbortProcessAction option. verifyModule() returns false, but does not abort and does not print out any information about what caused the verification to fail.
Chris Lattner wrote:
I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if AbortProcessAction is passed as parameter. Is this a bug?
Ryan M. Lefever wrote:
I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt?
Ryan M. Lefever wrote:
If verifyFunction() return false then it means it is not broken. I think you want
to use verifyModule() for your case.
Ryan,
I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt?
There's only two explanations for that:
1. The verifier isn't catching something it should
2. There's a bug in the bytecode reader/writer.
Reid.