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

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

This reverts commit r235458.

It looks like this might be breaking something LTO-ish. Looking into

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

This reverts commit r235458.

It looks like this might be breaking something LTO-ish. Looking into it
& will recommit with a fix/test case/etc once I've got more to go on.

llvm-svn: 235533

show more ...

Have more strict type checks when creating BinOp nodes in BitcodeReader

Summary: Bug found with AFL.

Reviewers: rafael, bkramer

Subscribers: llvm-commits

Differential Revision: http://reviews.llv

Have more strict type checks when creating BinOp nodes in BitcodeReader

Summary: Bug found with AFL.

Reviewers: rafael, bkramer

Subscribers: llvm-commits

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

llvm-svn: 235489

show more ...

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

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

[opaque pointer types] Serialize the value type for atomic 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.

llvm-svn: 235475

show more ...

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