IR / debug info: Add a DWOId field to DICompileUnit,
so DWARF skeleton CUs can be expression in IR. A skeleton CU is a
(typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and
a DW_A

IR / debug info: Add a DWOId field to DICompileUnit,
so DWARF skeleton CUs can be expression in IR. A skeleton CU is a
(typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and
a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info.

This is a prerequisite for clang module debugging as discussed in
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html.
In order to refer to external types stored in split DWARF (dwo) objects,
such as clang modules, we need to emit skeleton CUs, which identify the
dwarf object (i.e., the clang module) by filename (the SplitDebugFilename)
and a hash value, the dwo_id.

This patch only contains the IR changes. The idea is that a CUs with a
non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name
and DW_AT_GNU_dwo_id attribute.

http://reviews.llvm.org/D9488
rdar://problem/20091852

llvm-svn: 237949

show more ...

[BitcodeReader] Error out if we read an invalid function argument type

Bug found with AFL fuzz.

llvm-svn: 237650

[BitcodeReader] Make sure the type of the inserted value matches the type of the aggregate at those indices

Bug found with AFL-fuzz.

llvm-svn: 237628

Extract the load/store type verification to a separate function.

Summary:
Added isLoadableOrStorableType to PointerType.

We were doing some checks in some places, occasionally assert()ing instead
o

Extract the load/store type verification to a separate function.

Summary:
Added isLoadableOrStorableType to PointerType.

We were doing some checks in some places, occasionally assert()ing instead
of telling the caller. With this patch, I'm putting all type checking in
the same place for load/store type instructions, and verifying the same
thing every time.

I also added a check for load/store of a function type.

Applied extracted check to Load, Store, and Cmpxcg.

I don't have exhaustive tests for all of these, but all Error() calls in
TypeCheckLoadStoreInst are being tested (in invalid.test).

Reviewers: dblaikie, rafael

Subscribers: llvm-commits

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

llvm-svn: 237619

show more ...

[BitcodeReader] Don't allow INSERTVAL/EXTRACTVAL with 0 indices

This would trigger an assertion later.

Bug found with AFL fuzz.

llvm-svn: 237494

Remove redundant checks. NFC

llvm-svn: 237488

While in GlobalValue fix the function(s) that don't follow the
naming convention and update users.

llvm-svn: 237461

[opaque pointer type] Explicit pointee type for GEPOperator/GEPConstantExpr.

Also a couple of other changes to avoid use of
PointerType::getElementType here & there too.

llvm-svn: 236799

Don't overflow GCTable

Summary: Bug found with AFL fuzz.

Reviewers: rafael, dexonsmith

Subscribers: llvm-commits

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

llvm-svn: 236200

Make sure Op->getType() is a PointerType before we cast<> it.

Bug found with AFL fuzz.

llvm-svn: 236193

Make sure we don't resize(0) when we get a fwdref with Idx == UINT_MAX

Make it an error instead.

Bug found with AFL fuzz.

llvm-svn: 236190

[opaque pointer type] Pass GlobalAlias the actual pointer type rather than decomposing it into pointee type + address space

Many of the callers already have the pointer type anyway, and for the
coup

[opaque pointer type] Pass GlobalAlias the actual pointer type rather than decomposing it into pointee type + address space

Many of the callers already have the pointer type anyway, and for the
couple of callers that don't it's pretty easy to call PointerType::get
on the pointee type and address space.

This avoids LLParser from using PointerType::getElementType when parsing
GlobalAliases from IR.

llvm-svn: 236160

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

Use an "early return" idiom for the error case. NFC

llvm-svn: 236080

Check that we have a valid PointerType element type before calling get()

Same as r236073 but for PointerType.

Bug found with AFL fuzz.

llvm-svn: 236079

Use the ArrayType member function for array element types.

ArrayType and StructType accept the same types, so no test.

llvm-svn: 236078

Make sure that isValidElementType(Type) before calling {Array,Struct}Type::get(Type)

Bug found with AFL fuzz.

llvm-svn: 236073

Relax an assert when there's a type mismatch in forward references

Summary:
We don't seem to need to assert here, since this function's callers expect
to get a nullptr on error. This way we don't as

Relax an assert when there's a type mismatch in forward references

Summary:
We don't seem to need to assert here, since this function's callers expect
to get a nullptr on error. This way we don't assert on user input.

Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

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

llvm-svn: 236027

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

[BitcodeReader] Fix asserts when we read a non-vector type for insert/extract/shuffle

Added some additional checking for vector types + tests.

Bug found with AFL fuzz.

llvm-svn: 235710

Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst

(reverted in r235533)

Original commit message:

"Calls to llvm::Value::mutateType are bec

Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst

(reverted in r235533)

Original commit message:

"Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)"

The remapping done in ValueMapper for LTO was insufficient as the types
weren't correctly mapped (though I was using the post-mapped operands,
some of those operands might not have been mapped yet so the type
wouldn't be post-mapped yet). Instead use the pre-mapped type and
explicitly map all the types.

llvm-svn: 235651

show more ...