[LLVMdev] opt -verify

Reid Spencer rspencer at reidspencer.com
Thu Feb 22 14:48:27 PST 2007


On Thu, 22 Feb 2007 16:26:24 -0600
  "Ryan M. Lefever" <lefever at crhc.uiuc.edu> 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?

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.


> 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 
>> 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 
>>>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 
>>>>>(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?
>>>>Yes.  the passmanager runs the passes in roughly this 
>>>>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.
>>>>>opt: Reader.cpp:1978: llvm::Value*
>>>>>int): Assertion
>>>>>`(!isa<Constant>(Result) || 
>>>>>!cast<Constant>(Result)->isNullValue()) ||
>>>>>!hasImplicitNull(TypeID) && "Cannot read null values from 
>>>>>std::allocator<llvm::BytecodeReader::ValueList*> >&,
>>>>>std::allocator<llvm::PATypeHolder> >&,
>>>>>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> 
>>>>>std::char_traits<char>, std::allocator<char> 
>>>>>std::char_traits<char>, std::allocator<char> > const&,
>>>>>std::basic_string<char, std::char_traits<char>, 
>>>>>std::allocator<char> >*,
>>>>>std::char_traits<char>, std::allocator<char> > const&,
>>>>>std::basic_string<char, std::char_traits<char>, 
> -- 
> 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

More information about the llvm-dev mailing list