summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader
Commit message (Collapse)AuthorAgeFilesLines
* Explicitly handle LinkOnceODRAutoHideLinkage. NFC. We already have a test.Rafael Espindola2015-01-081-0/+2
| | | | llvm-svn: 225449
* Update naming style and clang-format. NFC.Rafael Espindola2015-01-081-17/+30
| | | | llvm-svn: 225448
* Fix Visual C++ error "'llvm::make_unique' : ambiguous call to overloaded ↵Yaron Keren2014-12-181-2/+2
| | | | | | function". llvm-svn: 224506
* Modernize the getStreamedBitcodeModule interface a bit. NFC.Rafael Espindola2014-12-181-18/+14
| | | | llvm-svn: 224499
* Bitcode: Add missing "Remove in 4.0" commentsDuncan P. N. Exon Smith2014-12-121-0/+2
| | | | llvm-svn: 224090
* Bitcode: Add METADATA_NODE and METADATA_VALUEDuncan P. N. Exon Smith2014-12-111-0/+21
| | | | | | | | | | | | | | | | This reflects the typelessness of `Metadata` in the bitcode format, removing types from all metadata operands. `METADATA_VALUE` represents a `ValueAsMetadata`, and always has two fields: the type and the value. `METADATA_NODE` represents an `MDNode`, and unlike `METADATA_OLD_NODE`, doesn't store types. It stores operands at their ID+1 so that `0` can reference `nullptr` operands. Part of PR21532. llvm-svn: 224073
* Bitcode: Add `OLD_` prefix to metadata node recordsDuncan P. N. Exon Smith2014-12-111-2/+2
| | | | | | | | I'm about to change these, so move the old ones out of the way. Part of PR21532. llvm-svn: 224070
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-092-47/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* IR: Disallow function-local metadata attachmentsDuncan P. N. Exon Smith2014-12-061-2/+6
| | | | | | | | Metadata attachments to instructions cannot be function-local. This is part of PR21532. llvm-svn: 223574
* IR: Disallow complicated function-local metadataDuncan P. N. Exon Smith2014-12-061-6/+30
| | | | | | | | | | Disallow complex types of function-local metadata. The only valid function-local metadata is an `MDNode` whose sole argument is a non-metadata function-local value. Part of PR21532. llvm-svn: 223564
* Ask the module for its the identified types.Rafael Espindola2014-12-032-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When lazy reading a module, the types used in a function will not be visible to a TypeFinder until the body is read. This patch fixes that by asking the module for its identified struct types. If a materializer is present, the module asks it. If not, it uses a TypeFinder. This fixes pr21374. I will be the first to say that this is ugly, but it was the best I could find. Some of the options I looked at: * Asking the LLVMContext. This could be made to work for gold, but not currently for ld64. ld64 will load multiple modules into a single context before merging them. This causes us to see types from future merges. Unfortunately, MappedTypes is not just a cache when it comes to opaque types. Once the mapping has been made, we have to remember it for as long as the key may be used. This would mean moving MappedTypes to the Linker class and having to drop the Linker::LinkModules static methods, which are visible from C. * Adding an option to ignore function bodies in the TypeFinder. This would fix the PR by picking the worst result. It would work, but unfortunately we are currently quite dependent on the upfront type merging. I will try to reduce our dependency, but it is not clear that we will be able to get rid of it for now. The only clean solution I could think of is making the Module own the types. This would have other advantages, but it is a much bigger change. I will propose it, but it is nice to have this fixed while that is discussed. With the gold plugin, this patch takes the number of types in the LTO clang binary from 52817 to 49669. llvm-svn: 223215
* Prologue supportPeter Collingbourne2014-12-032-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
* Add accessor marcos to ConstantPlaceHolder, similar to those in the base class.Richard Trieu2014-11-211-1/+2
| | | | llvm-svn: 222502
* Silence MSVC warning on missing return after fully covered switchReid Kleckner2014-11-131-0/+1
| | | | llvm-svn: 221943
* Move calls to push_back out of readAbbreviated(Literal|Field).Rafael Espindola2014-11-131-26/+13
| | | | | | | These functions always return a single value and not all callers want to push them into a SmallVector. llvm-svn: 221934
* Make a few helper functions static. NFC.Rafael Espindola2014-11-131-16/+18
| | | | llvm-svn: 221930
* Return the number of read bytes in MemoryObject::readBytes.Rafael Espindola2014-11-121-1/+1
| | | | | | | Returning more information will allow BitstreamReader to be simplified a bit and changed to read 64 bits at a time. llvm-svn: 221794
* Reduce code duplication a bit. NFC.Rafael Espindola2014-11-121-2/+2
| | | | llvm-svn: 221785
* Factor out call to push_back. NFC.Rafael Espindola2014-11-061-3/+5
| | | | llvm-svn: 221490
* Remove redundant calls to isMaterializable.Rafael Espindola2014-11-011-4/+2
| | | | | | | | | | This removes calls to isMaterializable in the following cases: * It was redundant with a call to isDeclaration now that isDeclaration returns the correct answer for materializable functions. * It was followed by a call to Materialize. Just call Materialize and check EC. llvm-svn: 221050
* Untabify.NAKAMURA Takumi2014-10-291-2/+2
| | | | llvm-svn: 220884
* Modernize the error handling of the Materialize function.Rafael Espindola2014-10-242-4/+4
| | | | llvm-svn: 220600
* Don't ever call materializeAllPermanently during LTO.Rafael Espindola2014-10-242-9/+3
| | | | | | | | | | To do this, change the representation of lazy loaded functions. The previous representation cannot differentiate between a function whose body has been removed and one whose body hasn't been read from the .bc file. That means that in order to drop a function, the entire body had to be read. llvm-svn: 220580
* clang-format two code snippets to make the next patch easy to read.Rafael Espindola2014-10-231-1/+2
| | | | llvm-svn: 220484
* Do not destroy external linkage when deleting function bodyPetar Jovanovic2014-09-231-1/+1
| | | | | | | | | | | The function deleteBody() converts the linkage to external and thus destroys original linkage type value. Lack of correct linkage type causes wrong relocations to be emitted later. Calling dropAllReferences() instead of deleteBody() will fix the issue. Differential Revision: http://reviews.llvm.org/D5415 llvm-svn: 218302
* Eliminating static destructor for the BitCodeErrorCategory by converting to ↵Chris Bieneman2014-09-191-2/+5
| | | | | | | | | | | | | | | | a ManagedStatic. Summary: This is part of the overall goal of removing static initializers from LLVM. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: chandlerc, llvm-commits Differential Revision: http://reviews.llvm.org/D5416 llvm-svn: 218149
* Use IntrusiveRefCntPtr to manage the lifetime of BitCodeAbbrevs.Benjamin Kramer2014-09-151-36/+3
| | | | | | | | | This doesn't change the interface or gives additional safety but removes a ton of retain/release boilerplate. No functionality change. llvm-svn: 217778
* Pass a && to getLazyBitcodeModule.Rafael Espindola2014-09-032-5/+6
| | | | | | | | This forces callers to use std::move when calling it. It is somewhat odd to have code with std::move that doesn't always move, but it is also odd to have code without std::move that sometimes moves. llvm-svn: 217049
* Fix a double free in llvm::getBitcodeTargetTriple.Rafael Espindola2014-08-271-1/+1
| | | | | | Unfortunately this is only used by ld64, so no testcase, but should fix the darwin LTO bootstrap. llvm-svn: 216618
* Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.Rafael Espindola2014-08-262-10/+13
| | | | | | | By taking a reference we can do the ownership transfer in one place instead of expecting every caller to do it. llvm-svn: 216492
* Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola2014-08-263-9/+10
| | | | | | | | | | | | | The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
* BitcodeReader: Only create one basic block for each blockaddressDuncan P. N. Exon Smith2014-08-162-20/+18
| | | | | | | | | | | | | | | | Block address forward-references are implemented by creating a `BasicBlock` ahead of time that gets inserted in the `Function` when it's eventually encountered. However, if the same blockaddress was used in two separate functions that were parsed *before* the referenced function (and the blockaddress was never used at global scope), two separate basic blocks would get created, one of which would be forgotten creating invalid IR. This commit changes the forward-reference logic to create only one basic block (and always return the same blockaddress). llvm-svn: 215805
* UseListOrder: Correctly count the number of usesDuncan P. N. Exon Smith2014-08-161-2/+2
| | | | | | | | | | This is an off-by-one bug I found by inspection, which would only trigger if the bitcode writer sees more uses of a `Value` than the reader. Since this is only relevant when an instruction gets upgraded somehow, there unfortunately isn't a reasonable way to add test coverage. llvm-svn: 215804
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* BitcodeReader: Fix non-determinism in use-list orderDuncan P. N. Exon Smith2014-08-052-3/+15
| | | | | | | | | | | | `BasicBlockFwdRefs` (and `BlockAddrFwdRefs` before it) was being emptied in a non-deterministic order. When predicting use-list order I've worked around this another way, but even when parsing lazily (and we can't recreate use-list order) use-lists should be deterministic. Make them so by using a side-queue of functions with forward-referenced blocks that gets visited in order. llvm-svn: 214899
* UseListOrder: Fix blockaddress use-list orderDuncan P. N. Exon Smith2014-08-011-6/+20
| | | | | | | | | | | | | | | | | | | `parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as a helper. Since `parseBitcodeFile()` isn't actually lazy -- it calls `MaterializeAllPermanently()` -- bypass the unnecessary call to `materializeForwardReferencedFunctions()` by extracting out a common helper function. This removes the last of the use-list churn caused by blockaddresses. This highlights that we can't reproduce use-list order of globals and constants when parsing lazily -- but that's necessarily out of scope. When we're parsing lazily, we never have all the functions in memory, so the use-lists of globals (and constants that reference globals) are always incomplete. This is part of PR5680. llvm-svn: 214581
* BitcodeReader: Change mechanics of BlockAddress forward references, NFCDuncan P. N. Exon Smith2014-08-012-38/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we can reliably handle forward references to `BlockAddress` (r214563), change the mechanics to simplify predicting use-list order. Previously, we created dummy `GlobalVariable`s to represent block addresses. After every function was materialized, we'd go through any forward references to its blocks and RAUW them with a proper `BlockAddress` constant. This causes some (potentially a lot of) unnecessary use-list churn, since any constant expression that it's a part of will need to be rematerialized as well. Instead, pre-construct a `BasicBlock` immediately -- without attaching it to its (empty) `Function` -- and use that to construct a `BlockAddress`. This constant will not have to be regenerated. When the function body is parsed, hook this pre-constructed basic block up in the right place using `BasicBlock::insertInto()`. Both before and after this change, the IR is temporarily in an invalid state that gets resolved when `materializeForwardReferencedFunctions()` gets called. This is a prep commit that's part of PR5680, but the only functionality change is the reduction of churn in the constant pool. llvm-svn: 214570
* BitcodeReader: Fix some BlockAddress forward reference corner casesDuncan P. N. Exon Smith2014-08-012-9/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | `BlockAddress`es are interesting in that they can reference basic blocks from *outside* the block's function. Since basic blocks are not global values, this presents particular challenges for lazy parsing. One corner case was found in PR11677 and fixed in r147425. In that case, a global variable references a block address. It's necessary to load the relevant function to resolve the forward reference before doing anything with the module. By inspection, I found (and have fixed here) two other cases: - An instruction from one function references a block address from another function, and only the first function is lazily loaded. I fixed this the same way as PR11677: by eagerly loading the referenced function. - A function whose block address is taken is dematerialized, leaving invalid references to it. I fixed this by refusing to dematerialize functions whose block addresses are taken (if you have to load it, you can't unload it). llvm-svn: 214559
* Have a single enum for "not a bitcode" error.Rafael Espindola2014-07-291-9/+3
| | | | | | | This is more convenient for callers. No functionality change, this will be used in a next patch to the gold plugin. llvm-svn: 214218
* Move the bitcode error enum to the include directory.Rafael Espindola2014-07-292-276/+248
| | | | | | | | This will let users in other libraries know which error occurred. In particular, it will be possible to check if the parsing failed or if the file is not bitcode. llvm-svn: 214209
* Bitcode: Serialize (and recover) use-list orderDuncan P. N. Exon Smith2014-07-282-7/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
* Add a dereferenceable attributeHal Finkel2014-07-181-1/+5
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Rename AlignAttribute to IntAttributeHal Finkel2014-07-181-1/+1
| | | | | | | | | | | | Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
* Roundtrip the inalloca bit on allocas through bitcodeReid Kleckner2014-07-161-2/+6
| | | | | | | | | | | | | This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
* Fix a bug in the conversion to ErrorOr.Rafael Espindola2014-07-041-2/+2
| | | | | | | | | The regular end of the bitcode parsing is in the BitstreamEntry::EndBlock case. Should fix the LTO bootstrap on OS X (this function is only used by ld64). llvm-svn: 212357
* Revert "Convert a few std::strings to StringRef."Rafael Espindola2014-07-042-25/+13
| | | | | | | | | This reverts commit r212342. We can get a StringRef into the current Record, but not one in the bitcode itself since the string is compressed in it. llvm-svn: 212356
* Convert a few std::strings to StringRef.Rafael Espindola2014-07-042-13/+25
| | | | llvm-svn: 212342
* Convert these functions to use ErrorOr.Rafael Espindola2014-07-042-10/+11
| | | | llvm-svn: 212341
* Remove unused old-style error handling.Rafael Espindola2014-07-041-5/+2
| | | | | | If needed, an ErrorOr should be used. llvm-svn: 212340
* IR: Add COMDATs to the IRDavid Majnemer2014-06-272-0/+45
| | | | | | | | | | | | | | | | This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
OpenPOWER on IntegriCloud