summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [BitcodeReader] Sanity check on Comdat IDFilipe Cabecinhas2015-05-261-2/+4
| | | | | | | | Shouldn't be an assert, since user input can trigger it. Bug found with AFL fuzz. llvm-svn: 238261
* IR / debug info: Add a DWOId field to DICompileUnit,Adrian Prantl2015-05-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | 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
* [BitcodeReader] Error out if we read an invalid function argument typeFilipe Cabecinhas2015-05-191-1/+4
| | | | | | Bug found with AFL fuzz. llvm-svn: 237650
* [BitcodeReader] Make sure the type of the inserted value matches the type of ↵Filipe Cabecinhas2015-05-181-0/+3
| | | | | | | | the aggregate at those indices Bug found with AFL-fuzz. llvm-svn: 237628
* Extract the load/store type verification to a separate function.Filipe Cabecinhas2015-05-181-9/+38
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [BitcodeReader] Don't allow INSERTVAL/EXTRACTVAL with 0 indicesFilipe Cabecinhas2015-05-161-4/+10
| | | | | | | | This would trigger an assertion later. Bug found with AFL fuzz. llvm-svn: 237494
* Remove redundant checks. NFCFilipe Cabecinhas2015-05-151-2/+0
| | | | llvm-svn: 237488
* While in GlobalValue fix the function(s) that don't follow theEric Christopher2015-05-151-4/+4
| | | | | | naming convention and update users. llvm-svn: 237461
* [opaque pointer type] Explicit pointee type for GEPOperator/GEPConstantExpr.David Blaikie2015-05-081-4/+6
| | | | | | | Also a couple of other changes to avoid use of PointerType::getElementType here & there too. llvm-svn: 236799
* Don't overflow GCTableFilipe Cabecinhas2015-04-301-1/+1
| | | | | | | | | | | | 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.Filipe Cabecinhas2015-04-301-0/+2
| | | | | | Bug found with AFL fuzz. llvm-svn: 236193
* Make sure we don't resize(0) when we get a fwdref with Idx == UINT_MAXFilipe Cabecinhas2015-04-301-0/+4
| | | | | | | | Make it an error instead. Bug found with AFL fuzz. llvm-svn: 236190
* [opaque pointer type] Pass GlobalAlias the actual pointer type rather than ↵David Blaikie2015-04-291-2/+1
| | | | | | | | | | | | | 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
* IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith2015-04-291-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use an "early return" idiom for the error case. NFCFilipe Cabecinhas2015-04-291-8/+6
| | | | llvm-svn: 236080
* Check that we have a valid PointerType element type before calling get()Filipe Cabecinhas2015-04-291-1/+2
| | | | | | | | Same as r236073 but for PointerType. Bug found with AFL fuzz. llvm-svn: 236079
* Use the ArrayType member function for array element types.Filipe Cabecinhas2015-04-291-1/+1
| | | | | | ArrayType and StructType accept the same types, so no test. llvm-svn: 236078
* Make sure that isValidElementType(Type) before calling ↵Filipe Cabecinhas2015-04-291-2/+4
| | | | | | | | {Array,Struct}Type::get(Type) Bug found with AFL fuzz. llvm-svn: 236073
* Relax an assert when there's a type mismatch in forward referencesFilipe Cabecinhas2015-04-281-1/+3
| | | | | | | | | | | | | | | | 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
* [opaque pointer type] Encode the allocated type of an alloca rather than its ↵David Blaikie2015-04-281-6/+13
| | | | | | pointer result type. llvm-svn: 235998
* [opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'David Blaikie2015-04-281-5/+8
| | | | | | | | | | | | | | | | | 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
* [opaque pointer type] encode the pointee type of global variablesDavid Blaikie2015-04-271-5/+11
| | | | | | | | | 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
* IR: Add assembly/bitcode support for function metadata attachmentsDuncan P. N. Exon Smith2015-04-241-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [opaque pointer type] bitcode: add explicit callee type to invoke instructionsDavid Blaikie2015-04-241-14/+23
| | | | llvm-svn: 235735
* [BitcodeReader] Fix asserts when we read a non-vector type for ↵Filipe Cabecinhas2015-04-241-2/+9
| | | | | | | | | | 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 ↵David Blaikie2015-04-231-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[opaque pointer type] Avoid using PointerType::getElementType for a ↵David Blaikie2015-04-221-6/+7
| | | | | | | | | | | 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
* Have more strict type checks when creating BinOp nodes in BitcodeReaderFilipe Cabecinhas2015-04-221-14/+29
| | | | | | | | | | | | Summary: Bug found with AFL. Reviewers: rafael, bkramer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9015 llvm-svn: 235489
* [opaque pointer types] Serialize the value type for atomic store instructionsDavid Blaikie2015-04-221-4/+8
| | | | | | | | 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
* [opaque pointer types] Serialize the value type for store instructionsDavid Blaikie2015-04-221-4/+8
| | | | | | | | | | 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
* [opaque pointer type] Avoid using PointerType::getElementType for a few ↵David Blaikie2015-04-211-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | cases of CallInst 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) llvm-svn: 235458
* [opaque pointer types] Use the pointee type loaded from bitcode when ↵David Blaikie2015-04-171-5/+6
| | | | | | | | | | constructing a LoadInst Now (with a few carefully placed suppressions relating to general type serialization, etc) we can round trip a simple load through bitcode and textual IR without calling getElementType on a PointerType. llvm-svn: 235221
* [opaque pointer type] Serialize the type of an llvm::Function as a function ↵David Blaikie2015-04-171-4/+3
| | | | | | type rather than a function pointer type llvm-svn: 235200
* [opaque pointer type] Explicit pointee type for call instructionDavid Blaikie2015-04-171-9/+22
| | | | | | | | | | 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
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DebugInfo: Remove 'inlinedAt:' field from MDLocalVariableDuncan P. N. Exon Smith2015-04-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Error out of ParseBitcodeInto(Module*) if we haven't read a ModuleFilipe Cabecinhas2015-04-141-2/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: Without this check the following case failed: Skip a SubBlock which is not a MODULE_BLOCK_ID nor a BLOCKINFO_BLOCK_ID Got to end of file TheModule would still be == nullptr, and we would subsequentially fail when materializing the Module (assert at the start of BitcodeReader::MaterializeModule). Bug found with AFL. Reviewers: dexonsmith, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9014 llvm-svn: 234887
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-1/+1
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-5/+8
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* git-clang-format r233603.Rafael Espindola2015-04-011-3/+1
| | | | | | Thanks to Meador Inge for noticing. llvm-svn: 233808
* Fix PR23045.Rafael Espindola2015-03-301-0/+12
| | | | | | | | | Keep a note in the materializer that we are stripping debug info so that user doing a lazy read of the module don't hit outdated formats. Thanks to Duncan for suggesting the fix. llvm-svn: 233603
* Verifier: Check accessors of MDLocationDuncan P. N. Exon Smith2015-03-261-3/+4
| | | | | | | | | | | | | | | | | | | | Check accessors of `MDLocation`, and change them to `cast<>` down to the right types. Also add type-safe factory functions. All the callers that handle broken code need to use the new versions of the accessors (`getRawScope()` instead of `getScope()`) that still return `Metadata*`. This is also necessary for things like `MDNodeKeyImpl<MDLocation>` (in LLVMContextImpl.h) that need to unique the nodes when their operands might still be forward references of the wrong type. In the `Value` hierarchy, consumers that handle broken code use `getOperand()` directly. However, debug info nodes have a ton of operands, and their order (even their existence) isn't stable yet. It's safer and more maintainable to add an explicit "raw" accessor on the class itself. llvm-svn: 233322
* Internalize BitcodeReader. Not used outside of BitcodeReader.cpp.Benjamin Kramer2015-03-171-2/+342
| | | | | | NFC. llvm-svn: 232542
* Add testing for mismatched explicit type on a gep operator when loading from ↵David Blaikie2015-03-161-1/+2
| | | | | | bitcode llvm-svn: 232427
* Add testing for mismatched explicit type on a load instruction when loading ↵David Blaikie2015-03-161-3/+3
| | | | | | from bitcode llvm-svn: 232424
* Test bitcode parsing error-handling for incorrect explicit typeDavid Blaikie2015-03-161-2/+8
| | | | | | | | (turns out I had regressed this when sinking handling of this type down into GetElementPtrInst::Create - since that asserted before the error handling was performed) llvm-svn: 232420
* [opaque pointer type] more gep API migrationDavid Blaikie2015-03-141-1/+1
| | | | llvm-svn: 232274
* [opaque pointer type] Bitcode support for explicit type parameter on the gep ↵David Blaikie2015-03-131-5/+11
| | | | | | | | | | | | | | 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
* Turn assertion into bitcode reading errorDavid Blaikie2015-03-131-2/+2
| | | | | | | | I don't think we test invalid bitcode records in any detail, so no test here - just a change for consistency with existing error checks in surrounding code. llvm-svn: 232215
* Add a parameter for getLazyBitcodeModule to lazily load Metadata.Manman Ren2015-03-131-9/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | We only defer loading metadata inside ParseModule when ShouldLazyLoadMetadata is true and we have not loaded any Metadata block yet. This commit implements all-or-nothing loading of Metadata. If there is a request to load any metadata block, we will load all deferred metadata blocks. We make sure the deferred metadata blocks are loaded before we materialize any function or a module. The default value of the added parameter ShouldLazyLoadMetadata for getLazyBitcodeModule is false, so the default behavior stays the same. We only set the parameter to true when creating LTOModule in local contexts. These can only really be used for parsing symbols, so it's unnecessary to ever load the metadata blocks. If we are going to enable lazy-loading of Metadata for other usages of getLazyBitcodeModule, where deferred metadata blocks need to be loaded, we can expose BitcodeReader::materializeMetadata to Module, similar to Module::materialize. rdar://19804575 llvm-svn: 232198
OpenPOWER on IntegriCloud