summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* [opaque pointer type] Encode the allocated type of an alloca rather than its ↵David Blaikie2015-04-282-8/+16
| | | | | | pointer result type. llvm-svn: 235998
* [opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'David Blaikie2015-04-282-6/+9
| | | | | | | | | | | | | | | | | 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-272-12/+20
| | | | | | | | | 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-243-5/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-242-18/+27
| | | | 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
* Be more strict about the operand for the array type in BitcodeReaderFilipe Cabecinhas2015-04-231-0/+3
| | | | | | | | | | | | Summary: Bug found with AFL fuzz. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9016 llvm-svn: 235596
* Verify sizes when trying to read a BitcodeAbbrevOpFilipe Cabecinhas2015-04-231-0/+9
| | | | | | | | | | | | | | | | Summary: Make sure the abbrev operands are valid and that we can read/skip them afterwards. Bug found with AFL fuzz. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9030 llvm-svn: 235595
* 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-222-5/+9
| | | | | | | | | | 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-172-5/+4
| | | | | | type rather than a function pointer type llvm-svn: 235200
* [opaque pointer type] Explicit pointee type for call instructionDavid Blaikie2015-04-172-12/+25
| | | | | | | | | | 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-162-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-152-3/+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
* Revert "Verify sizes when trying to read a VBR"Filipe Cabecinhas2015-04-151-2/+0
| | | | | | | This reverts r234984 since it seems to break some bots (most of them seemed arm*-selfhost). llvm-svn: 234998
* Verify sizes when trying to read a VBRFilipe Cabecinhas2015-04-151-0/+2
| | | | | | Also added an assert to ReadVBR64. llvm-svn: 234984
* uselistorder: Remove the global bitsDuncan P. N. Exon Smith2015-04-151-1/+0
| | | | | | | | | | | | | Remove all the global bits to do with preserving use-list order by moving the `cl::opt`s to the individual tools that want them. There's a minor functionality change to `libLTO`, in that you can't send in `-preserve-bc-uselistorder=false`, but making that bit settable (if it's worth doing) should be through explicit LTO API. As a drive-by fix, I removed some includes of `UseListOrder.h` that were made unnecessary by recent commits. llvm-svn: 234973
* uselistorder: Pull bit through BitcodeWriterPassDuncan P. N. Exon Smith2015-04-151-6/+10
| | | | | | | Now the callers of `BitcodeWriterPass` decide whether or not to preserve bitcode use-list order. llvm-svn: 234959
* uselistorder: Pull the bit through WriteToBitcodFile()Duncan P. N. Exon Smith2015-04-152-6/+9
| | | | | | | | | | | 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
* uselistorder: Thread bit through ValueEnumeratorDuncan P. N. Exon Smith2015-04-143-8/+16
| | | | | | | | 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
* 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
* DebugInfo: Make MDSubprogram::getFunction() return ConstantDuncan P. N. Exon Smith2015-04-111-2/+2
| | | | | | | | Change `MDSubprogram::getFunction()` and `MDGlobalVariable::getConstant()` to return a `Constant`. Previously, both returned `ConstantAsMetadata`. llvm-svn: 234699
* 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
* IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*()Duncan P. N. Exon Smith2015-04-071-10/+10
| | | | | | | | | | | | 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
* IR: Rename MDSubrange::getLo() to getLowerBound()Duncan P. N. Exon Smith2015-04-071-1/+1
| | | | | | | During initial review, the `lo:` field was renamed to `lowerBound:`. Make the same change to the C++ API. llvm-svn: 234267
* [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
* IR: Use the new DebugLoc API, NFCDuncan P. N. Exon Smith2015-03-302-20/+11
| | | | | | | | 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
* Bitcode: Reflow code to use early continues, NFCDuncan P. N. Exon Smith2015-03-301-15/+18
| | | | llvm-svn: 233578
* 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-172-385/+342
| | | | | | NFC. llvm-svn: 232542
* AsmWriter: Assert on unresolved metadata nodesDuncan P. N. Exon Smith2015-03-171-0/+2
| | | | | | | | | | | | 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
* 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
* Be lazy about loading metadata in IRObjectFile.Rafael Espindola2015-03-131-1/+1
| | | | | | | This speeds up llvm-ar building lib64/libclangSema.a with debug IR files from 8.658015807 seconds to just 0.351036519 seconds :-) llvm-svn: 232221
* [opaque pointer type] Bitcode support for explicit type parameter on the gep ↵David Blaikie2015-03-132-7/+16
| | | | | | | | | | | | | | 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-132-11/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify expressions involving boolean constants with clang-tidyDavid Blaikie2015-03-091-1/+1
| | | | | | | | Patch by Richard (legalize at xmission dot com). Differential Revision: http://reviews.llvm.org/D8154 llvm-svn: 231617
* Add missing includes. make_unique proliferated everywhere.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230909
* Silence three more variable set but not used warnings, NFC.Yaron Keren2015-02-281-0/+3
| | | | llvm-svn: 230853
* [opaque pointer type] Bitcode support for explicit type parameter on GEP.David Blaikie2015-02-252-7/+37
| | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud