[llvm-dev] llvm::UpgradeDebugInfo does a full verification

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 25 08:56:15 PST 2018



> On Jan 24, 2018, at 10:47 PM, Carlo Kok <ck at remobjects.com> wrote:
> 
> 
> 
> Op 24-1-2018 om 18:26 schreef Adrian Prantl:
>>> On Jan 23, 2018, at 11:01 PM, Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I noticed that since recently UpgradeDebugInfo (Which is called for loading any bitcode from disk/memory) does a full bitcode verification. Is this on purpose or is this a mistake? Seems to have a fair amount of overhead.
>> That is be design, though there are bugs in the LTO pipeline where we run the Verifier more than once. "Upgrading" debug info means checking for a malformed metadata graph (for example, produced by older, buggy versions of LLVM, or buggy frontends) that would crash LLVM. The "upgrade" consists of stripping the debug info form the module.
> 
> Yeah I read that. My problem is that I use these calls to feed llvm my generated bitcode (I don't use the llvm apis, I write bitcode and give the endresult to llvm); now there's a fairly noticable overhead in loading this code into llvm and there doesn't seem to be a "load bitcode and skips checks" call I can use instead.

For testing purposes, opt and llc provide an option to not run the Verifier, but want to strongly discourage using this for anything besides writing testcases. IMHO whenever data is passed to LLVM, LLVM should run the verifier once. Does the overhead of the verifier show up in the profile? If so, is there a specific part that is slowing things down? The verifier checks should be mostly O(n) with the occasional DenseMap lookup. If improving the performance of the Verifier is an option I would rather like to go down this route.

-- adrian


More information about the llvm-dev mailing list