Strange LLVM behavior after commit r193719

[Michael Kruse]

Hi Ilia,

you are right, verifying the whole module when only verification of the
Module is requested is not desirable. My path however prevented crashing
the verifier in presence of debug infos, even less desirable. Given that
Verifier is a FunctionPass, letting it do module-level verification seems
counter-intuitive. I suggest the following solutions:

1. Quick fix: Remove the call to doFinalization in verifyFunction(), keep
the doInitialization.Skips most of the module-level verifications.

2. Better: Introduce a new ModuleVerifier pass and move the module-level
verifications there.

Michael







2013/11/13 Dmitry Babokin <babokin at gmail.com>

> Adding llvm-commits alias.
>
>
> On Tue, Nov 12, 2013 at 2:05 PM, Ilia Filippov <ili.filippov at gmail.com>wrote:
>
>> Hi Michael,
>>
>> Looks like your recent commit (r193719) has undesired / not intended side
>> effect. Doing *function* verification we end up verifying module's global
>> values.
>> Here's a call stack, which leads to such behavior:
>>
>> #0  ::Verifier::doFinalization (this=0x490c110, M=...) at
>> lib/IR/Verifier.cpp:199
>> #1  llvm::FPPassManager::doFinalization (this=0x490bf60, M=...) at
>> lib/IR/LegacyPassManager.cpp:1576
>> #2  llvm::legacy::FunctionPassManagerImpl::doFinalization
>> (this=0x490bc60, M=...) at lib/IR/LegacyPassManager.cpp:1448
>> #3  llvm::legacy::FunctionPassManager::doFinalization
>> (this=0x7fffffffd100) at lib/IR/LegacyPassManager.cpp:1420
>> #4  llvm::verifyFunction (f=..., action=llvm::ReturnStatusAction) at
>> lib/IR/Verifier.cpp:2405
>>
>> Where #4 is in the function verifyFunction, that you've modified, and #0
>> contains the loop over all module global values:
>>
>>     bool doFinalization(Module &M) {
>>       // Scan through, checking all of the external function's linkage
>> now...
>>       for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I) {
>>         visitGlobalValue(*I);
>>         <...>
>>
>> So you call a part of whole module verification inside function
>> verification routine. This seems to be incorrect first of all (and leads to
>> fails in our project based on LLVM, for example) and also inefficient
>> (doing the same module walk for each function).
>>
>> Any thoughts how to fix it?
>>
>> Thanks!
>>
>> Ilia.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131113/6926c649/attachment.html>