llvm dev - Jan 2018 - llvm::UpgradeDebugInfo does a full verification

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.

> 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.

-- adrian

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.