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

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

Prefer SmallVector::append/insert over push_back loops.

Same functionality, but hoists the vector growth out of the loop.

llvm-svn: 229500

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