Duncan P. N. Exon Smith b7685c9410 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		2015-02-16 19:18:01 +00:00
..
Reader	Bitcode: Fix major regression: large files w/ debug info	2015-02-16 19:18:01 +00:00
Writer	Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition.	2015-02-15 22:54:22 +00:00
CMakeLists.txt
LLVMBuild.txt
Makefile
module.modulemap