Bitcode: Set LastDL after writing DebugLocs

Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN`
records since. Add it back. Also tests that the output assembly looks
okay.

Fix

Bitcode: Set LastDL after writing DebugLocs

Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN`
records since. Add it back. Also tests that the output assembly looks
okay.

Fixes PR23436.

llvm-svn: 236661

show more ...

IR: Give 'DI' prefix to debug info metadata

Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`. The last of the `DIDescriptor` classes were deleted in
r235356, and the

IR: Give 'DI' prefix to debug info metadata

Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`. The last of the `DIDescriptor` classes were deleted in
r235356, and the last of the related typedefs removed in r235413, so
this has all baked for about a week.

Note: If you have out-of-tree code (like a frontend), I recommend that
you get everything compiling and tests passing with the *previous*
commit before updating to this one. It'll be easier to keep track of
what code is using the `DIDescriptor` hierarchy and what you've already
updated, and I think you're extremely unlikely to insert bugs. YMMV of
course.

Back to *this* commit: I did this using the rename-md-di-nodes.sh
upgrade script I've attached to PR23080 (both code and testcases) and
filtered through clang-format-diff.py. I edited the tests for
test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns
were off-by-three. It should work on your out-of-tree testcases (and
code, if you've followed the advice in the previous paragraph).

Some of the tests are in badly named files now (e.g.,
test/Assembler/invalid-mdcompositetype-missing-tag.ll should be
'dicompositetype'); I'll come back and move the files in a follow-up
commit.

llvm-svn: 236120

show more ...

[opaque pointer type] Encode the allocated type of an alloca rather than its pointer result type.

llvm-svn: 235998

[opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'

As a space optimization, this instruction would just encode the pointer
type of the first operand and use the knowledge tha

[opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'

As a space optimization, this instruction would just encode the pointer
type of the first operand and use the knowledge that the second and
third operands would be of the pointee type of the first. When typed
pointers go away, this assumption will no longer be available - so
encode the type of the second operand explicitly and rely on that for
the third.

Test case added to demonstrate the backwards compatibility concern,
which only comes up when the definition of the second operand comes
after the use (hence the weird basic block sequence) - at which point
the type needs to be explicitly encoded in the bitcode and the record
length changes to accommodate this.

llvm-svn: 235966

show more ...

[opaque pointer type] encode the pointee type of global variables

Use a few extra bits in the const field (after widening it from a fixed
single bit) to stash the address space which is no longer pr

[opaque pointer type] encode the pointee type of global variables

Use a few extra bits in the const field (after widening it from a fixed
single bit) to stash the address space which is no longer provided by
the type (and an extra bit in there to specify that we're using that new
encoding).

llvm-svn: 235911

show more ...

IR: Add assembly/bitcode support for function metadata attachments

Add serialization support for function metadata attachments (added in
r235783). The syntax is:

define @foo() !attach !0 {

Me

IR: Add assembly/bitcode support for function metadata attachments

Add serialization support for function metadata attachments (added in
r235783). The syntax is:

define @foo() !attach !0 {

Metadata attachments are only allowed on functions with bodies. Since
they come before the `{`, they're not really part of the body; since
they require a body, they're not really part of the header. In
`LLParser` I gave them a separate function called from `ParseDefine()`,
`ParseOptionalFunctionMetadata()`.

In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by
instructions. Instruction metadata attachments are included in a
special "attachment" block at the end of a `Function`. The attachment
records are laid out like this:

InstID (KindID MetadataID)+

Note that these records always have an odd number of fields. The new
code takes advantage of this to recognize function attachments (which
don't need an instruction ID):

(KindID MetadataID)+

This means we can use the same attachment block already used for
instructions.

This is part of PR23340.

llvm-svn: 235785

show more ...

[opaque pointer type] bitcode: add explicit callee type to invoke instructions

llvm-svn: 235735

[opaque pointer types] Serialize the value type for store instructions

Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add t

[opaque pointer types] Serialize the value type for store instructions

Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add the extra type
information that would be missing.

Storeatomic coming soon.

llvm-svn: 235474

show more ...

[opaque pointer type] Serialize the type of an llvm::Function as a function type rather than a function pointer type

llvm-svn: 235200

[opaque pointer type] Explicit pointee type for call instruction

Use an extra bit in the CCInfo to flag the newer version of the
instructiont hat includes the type explicitly.

Tested the newer erro

[opaque pointer type] Explicit pointee type for call instruction

Use an extra bit in the CCInfo to flag the newer version of the
instructiont hat includes the type explicitly.

Tested the newer error cases I added, but didn't add tests for the finer
granularity improvements to existing error paths.

llvm-svn: 235160

show more ...

[IR] Introduce a dereferenceable_or_null(N) attribute.

Summary:
If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it
is either `null` or `dereferenceable(N)` or both. This change o

[IR] Introduce a dereferenceable_or_null(N) attribute.

Summary:
If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it
is either `null` or `dereferenceable(N)` or both. This change only
introduces the attribute and adds a token test case for the `llvm-as`
/ `llvm-dis`. It does not hook up other parts of the optimizer to
actually exploit the attribute -- those changes will come later.

For pointers in address space 0, `dereferenceable(N)` is now exactly
equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other
address spaces, `dereferenceable(N)` is potentially weaker than
`dereferenceable_or_null(N)` && `nonnull` (since we could have a null
`dereferenceable(N)` pointer).

The motivating case for this change is Java (and other managed
languages), where pointers are either `null` or dereferenceable up to
some usually known-at-compile-time constant offset.

Reviewers: rafael, hfinkel

Reviewed By: hfinkel

Subscribers: nicholas, llvm-commits

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

llvm-svn: 235132

show more ...

DebugInfo: Remove 'inlinedAt:' field from MDLocalVariable

Remove 'inlinedAt:' from MDLocalVariable. Besides saving some memory
(variables with it seem to be single largest `Metadata` contributer to

DebugInfo: Remove 'inlinedAt:' field from MDLocalVariable

Remove 'inlinedAt:' from MDLocalVariable. Besides saving some memory
(variables with it seem to be single largest `Metadata` contributer to
memory usage right now in -g -flto builds), this stops optimization and
backend passes from having to change local variables.

The 'inlinedAt:' field was used by the backend in two ways:

1. To tell the backend whether and into what a variable was inlined.
2. To create a unique id for each inlined variable.

Instead, rely on the 'inlinedAt:' field of the intrinsic's `!dbg`
attachment, and change the DWARF backend to use a typedef called
`InlinedVariable` which is `std::pair<MDLocalVariable*, MDLocation*>`.
This `DebugLoc` is already passed reliably through the backend (as
verified by r234021).

This commit removes the check from r234021, but I added a new check
(that will survive) in r235048, and changed the `DIBuilder` API in
r235041 to require a `!dbg` attachment whose 'scope:` is in the same
`MDSubprogram` as the variable's.

If this breaks your out-of-tree testcases, perhaps the script I used
(mdlocalvariable-drop-inlinedat.sh) will help; I'll attach it to PR22778
in a moment.

llvm-svn: 235050

show more ...

uselistorder: Pull the bit through WriteToBitcodFile()

Change the callers of `WriteToBitcodeFile()` to pass `true` or
`shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers
that want

uselistorder: Pull the bit through WriteToBitcodFile()

Change the callers of `WriteToBitcodeFile()` to pass `true` or
`shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers
that want to send `false` alone.

I'll keep pushing the bit higher until hopefully I can delete the global
`cl::opt` entirely.

llvm-svn: 234957

show more ...

uselistorder: Thread bit through ValueEnumerator

Canonicalize access to whether to preserve use-list order in bitcode on
a `bool` stored in `ValueEnumerator`. Next step, expose this as a
`bool` thr

uselistorder: Thread bit through ValueEnumerator

Canonicalize access to whether to preserve use-list order in bitcode on
a `bool` stored in `ValueEnumerator`. Next step, expose this as a
`bool` through `WriteBitcodeToFile()`.

llvm-svn: 234956

show more ...

DebugInfo: Make MDSubprogram::getFunction() return Constant

Change `MDSubprogram::getFunction()` and
`MDGlobalVariable::getConstant()` to return a `Constant`. Previously,
both returned `ConstantAsM

DebugInfo: Make MDSubprogram::getFunction() return Constant

Change `MDSubprogram::getFunction()` and
`MDGlobalVariable::getConstant()` to return a `Constant`. Previously,
both returned `ConstantAsMetadata`.

llvm-svn: 234699

show more ...

IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*()

Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes
ambiguity (at least in some [1] compilers [2]) when using indexes to

IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*()

Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes
ambiguity (at least in some [1] compilers [2]) when using indexes to
`MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to
(but not the same as) `unsigned`.

[1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308
[2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442

llvm-svn: 234326

show more ...

IR: Rename MDSubrange::getLo() to getLowerBound()

During initial review, the `lo:` field was renamed to `lowerBound:`.
Make the same change to the C++ API.

llvm-svn: 234267

IR: Use the new DebugLoc API, NFC

Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an
explicit conversion to `bool` (avoiding a conversion to `MDLocation`),
since a couple of thes

IR: Use the new DebugLoc API, NFC

Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an
explicit conversion to `bool` (avoiding a conversion to `MDLocation`),
since a couple of these use cases need to handle broken code.

llvm-svn: 233585

show more ...

Bitcode: Reflow code to use early continues, NFC

llvm-svn: 233578

AsmWriter: Assert on unresolved metadata nodes

Assert that `MDNode::isResolved()`. While in theory the `Verifier`
should catch this, it doesn't descend into all debug info, and the
`DebugInfoVerifi

AsmWriter: Assert on unresolved metadata nodes

Assert that `MDNode::isResolved()`. While in theory the `Verifier`
should catch this, it doesn't descend into all debug info, and the
`DebugInfoVerifier` doesn't call into the `Verifier`. Besides, this
helps to catch bugs when `-disable-verify=true`.

Note that I haven't come across a place where this fails with clang
today, so no testcase.

llvm-svn: 232442

show more ...

[opaque pointer type] Bitcode support for explicit type parameter on the gep operator

This happened to be fairly easy to support backwards compatibility based
on the number of operands (old format h

[opaque pointer type] Bitcode support for explicit type parameter on the gep operator

This happened to be fairly easy to support backwards compatibility based
on the number of operands (old format had an even number, new format has
one more operand so an odd number).

test/Bitcode/old-aliases.ll already appears to test old gep operators
(if I remove the backwards compatibility in the BitcodeReader, this and
another test fail) so I'm not adding extra test coverage here.

llvm-svn: 232216

show more ...

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

BitcodeWriter: Refactor common computation of bits required for a type index.

Suggested by Duncan. Happy to bikeshed the name, cache the result, etc.

llvm-svn: 230410

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