Bitcode: Fix major regression: large files w/ debug info
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>
Mon, 16 Feb 2015 19:18:01 +0000 (19:18 +0000)
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>
Mon, 16 Feb 2015 19:18:01 +0000 (19:18 +0000)
commitb7685c941099661794cae120e987f3d4c6a4b9bf
tree9c683f0346a29ea784315f83af4fa4b0e860ca37
parente6e5eaa50d128f11a8174bc8a89d880f0fbe70f4
Bitcode: Fix major regression: large files w/ debug info

The metadata/value split introduced a major regression reading large
bitcode files that contain debug info (or other cyclic (non-self
reference) metadata graphs).  For the first time in a while, I dropped
from libLTO.dylib down to `llvm-lto` with a non-trivial bitcode file
(~350MB), and I hit this when reading the result of ld64's `-save-temps`
in `llvm-lto`.

Here's pseudo-code for what was going on:

    read-main-metadata-block:
      for each md:
        if has-fwd-ref: // Only true for cyclic graphs.
          any-fwd-refs <- true
      if any-fwd-refs:
        foreach md:
          resolve-cycles(md) // Handle cycles.

    foreach function:
      read-function-metadata-block: // Such as !alias, !loop
        if any-fwd-refs:
          foreach md: // (all metadata, not just this block)
            resolve-cycles(md) // A no-op, but the loop is expensive!!

This commit resets the `AnyFwdRefs` flag to `false`.  This on its own
was enough to change my Release+Asserts `llvm-lto` time for reading this
bitcode from over 20 minutes (I gave up on it) to 20 seconds.  I've gone
further by tracking the min/max metadata forward-references in a
metadata block.  This protects against a schema that has lots of
functions that each reference their own metadata cycle.

Unfortunately, this regression is in the 3.6 branch as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229421 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Bitcode/Reader/BitcodeReader.cpp
lib/Bitcode/Reader/BitcodeReader.h