Silence three more variable set but not used warnings, NFC.

llvm-svn: 230853

[opaque pointer type] Bitcode support for explicit type parameter on GEP.

Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggesti

[opaque pointer type] Bitcode support for explicit type parameter on GEP.

Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

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

llvm-svn: 230415

show more ...

[opaque pointer type] bitcode support for explicit type parameter to the load instruction

Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections wou

[opaque pointer type] bitcode support for explicit type parameter to the load instruction

Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections would be great.

This seems to pass all the tests (check-all, covering clang and llvm) so I
believe that pretty well exercises both the backwards compatibility and common
(same version) compatibility given the number of checked in bitcode files we
already have. Is that a reasonable approach to testing here? Would some more
explicit tests be desired?

1) is this the right way to do back-compat in this case (looking at the number
of entries in the bitcode record to disambiguate between the old schema and
the new?)

2) I don't quite understand the logarithm logic to choose the encoding type of
the type parameter in the abbreviation description, but I found another
instruction doing the same thing & it seems to work. Is that the right
approach?

Reviewers: dexonsmith

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

llvm-svn: 230414

show more ...

Use common parse routine to read alignment values from bitcode

While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2)

Use common parse routine to read alignment values from bitcode

While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem.

This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic.

Patch by Karl Schimpf (kschimpf@google.com).

llvm-svn: 230180

show more ...

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