Bitcode: Stop assuming non-null fields

When writing the bitcode serialization for the new debug info hierarchy,
I assumed two fields would never be null.

Drop that assumption, since it's brittle (a

Bitcode: Stop assuming non-null fields

When writing the bitcode serialization for the new debug info hierarchy,
I assumed two fields would never be null.

Drop that assumption, since it's brittle (and crashes the
`BitcodeWriter` if wrong), and is a check better left for the verifier
anyway. (No need for a bitcode upgrade here, since the new hierarchy is
still not in place.)

The fields in question are `MDCompileUnit::getFile()` and
`MDDerivedType::getBaseType()`, the latter of which isn't null in
test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to
nothing). While the testcase might have bitrotted, there's no reason
for the bitcode format to rely on non-null for metadata operands.

This also fixes a bug in `AsmWriter` where if the `file:` is null it
isn't emitted (caught by the double-round trip in the testcase I'm
adding) -- this is a required field in `LLParser`.

I'll circle back to ConvertDebugInfo2. Once the specialized nodes are
in place, I'll be trying to turn the debug info verifier back on by
default (in the newer module pass form committed r206300) and throwing
more logic in there. If the testcase has bitrotted (as opposed to me
not understanding the schema correctly) I'll fix it then.

llvm-svn: 229960

show more ...

IR: Drop scope from MDTemplateParameter

Follow-up to r229740, which removed `DITemplate*::getContext()` after my
upgrade script revealed that scopes are always `nullptr` for template
parameters. Th

IR: Drop scope from MDTemplateParameter

Follow-up to r229740, which removed `DITemplate*::getContext()` after my
upgrade script revealed that scopes are always `nullptr` for template
parameters. This is the other shoe: drop `scope:` from
`MDTemplateParameter` and its two subclasses. (Note: a bitcode upgrade
would be pointless, since the hierarchy hasn't been moved into place.)

llvm-svn: 229791

show more ...

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
referen

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.

llvm-svn: 229421

show more ...

[Bitcode reader] Fix a few assertions when reading invalid files

Summary:
When creating {insert,extract}value instructions from a BitcodeReader, we
weren't verifying the fields were valid.

Bugs fou

[Bitcode reader] Fix a few assertions when reading invalid files

Summary:
When creating {insert,extract}value instructions from a BitcodeReader, we
weren't verifying the fields were valid.

Bugs found with afl-fuzz

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7325

llvm-svn: 229345

show more ...

Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition.

llvm-svn: 229340

AsmWriter/Bitcode: MDImportedEntity

llvm-svn: 229025

AsmWriter/Bitcode: MDObjCProperty

llvm-svn: 229024

AsmWriter/Bitcode: MDExpression

llvm-svn: 229023

AsmWriter/Bitcode: MDLocalVariable

llvm-svn: 229022

AsmWriter/Bitcode: MDGlobalVariable

llvm-svn: 229020

AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter

llvm-svn: 229019

AsmWriter/Bitcode: MDNamespace

llvm-svn: 229018

AsmWriter/Bitcode: MDLexicalBlockFile

llvm-svn: 229017

AsmWriter/Bitcode: MDLexicalBlock

llvm-svn: 229016

AsmWriter/Bitcode: MDSubprogram

llvm-svn: 229014

AsmWriter/Bitcode: MDCompileUnit

llvm-svn: 229013

AsmWriter/Bitcode: MDSubroutineType

llvm-svn: 229011

AsmWriter/Bitcode: MDDerivedType and MDCompositeType

llvm-svn: 229009

AsmWriter/Bitcode: MDFile

llvm-svn: 229007

AsmWriter/Bitcode: MDBasicType

llvm-svn: 229005

AsmWriter/Bitcode: MDEnumerator

llvm-svn: 229004

AsmWriter/Bitcode: MDSubrange

llvm-svn: 229003

Misc documentation/comment fixes.

llvm-svn: 228093

IR: Assembly and bitcode for GenericDebugNode

llvm-svn: 228041

IR: Split out DebugInfoMetadata.h, NFC

Move debug-info-centred `Metadata` subclasses into their own
header/source file. A couple of private template functions are needed
from both `Metadata.cpp` an

IR: Split out DebugInfoMetadata.h, NFC

Move debug-info-centred `Metadata` subclasses into their own
header/source file. A couple of private template functions are needed
from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them
to `lib/IR/MetadataImpl.h`.

llvm-svn: 227835

show more ...