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:> On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >> 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 >-- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever]
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 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: > >>On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >> >>>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 >> > >-- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever]
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:> 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 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: >> >> >>>On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >>> >>> >>>>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 >>> >> >> >-- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever]
On Feb 22, 2007, at 2:17 PM, Ryan M. Lefever 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.If verifyFunction() return false then it means it is not broken. I think you want to use verifyModule() for your case. - Devang> 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 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: >> >>> On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >>> >>>> 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 >>> >> >> > > -- > Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev