summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader
Commit message (Collapse)AuthorAgeFilesLines
...
* AsmWriter/Bitcode: MDSubrangeDuncan P. N. Exon Smith2015-02-131-0/+12
| | | | llvm-svn: 229003
* Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.Zachary Turner2015-02-111-0/+3
| | | | | | | | | | This allows IDEs to recognize the entire set of header files for each of the core LLVM projects. Differential Revision: http://reviews.llvm.org/D7526 Reviewed By: Chris Bieneman llvm-svn: 228798
* Misc documentation/comment fixes.Peter Collingbourne2015-02-041-1/+2
| | | | llvm-svn: 228093
* IR: Assembly and bitcode for GenericDebugNodeDuncan P. N. Exon Smith2015-02-031-0/+32
| | | | llvm-svn: 228041
* Propagate a better error message to the C api.Rafael Espindola2015-02-031-3/+5
| | | | llvm-svn: 227934
* Use a non-fatal diag handler in the C API. FIxes PR22368.Rafael Espindola2015-02-031-2/+11
| | | | llvm-svn: 227903
* IR: Split out DebugInfoMetadata.h, NFCDuncan P. N. Exon Smith2015-02-021-0/+1
| | | | | | | | | Move debug-info-centred `Metadata` subclasses into their own header/source file. A couple of private template functions are needed from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them to `lib/IR/MetadataImpl.h`. llvm-svn: 227835
* Check bit widths before trying to get a type.Filipe Cabecinhas2015-01-301-2/+7
| | | | | | | | | Added a test case for it. Also added run lines for the test case in r227566. Bugs found with afl-fuzz llvm-svn: 227589
* [bitcode reader] Fix an assert on invalid type tablesFilipe Cabecinhas2015-01-301-1/+3
| | | | | | Bug found with afl-fuzz llvm-svn: 227566
* [Bitcode] Diagnose errors instead of asserting from bad inputFilipe Cabecinhas2015-01-241-1/+5
| | | | | | | | | | | | | | | Eventually we can make some of these pass the error along to the caller. Reports a fatal error if: We find an invalid abbrev record We try to get an invalid abbrev number We can't fill the current word due to an EOF Fixed an invalid bitcode test to check for output with FileCheck Bugs found with afl-fuzz llvm-svn: 226986
* Bitcode: Don't create comdats when autoupgrading macho bitcodeDavid Majnemer2015-01-201-2/+9
| | | | | | | Don't infer COMDAT groups from older bitcode if the target is macho, it doesn't have COMDATs. llvm-svn: 226546
* IR: Merge UniquableMDNode back into MDNode, NFCDuncan P. N. Exon Smith2015-01-191-1/+1
| | | | | | | | | As pointed out in r226501, the distinction between `MDNode` and `UniquableMDNode` is confusing. When we need subclasses of `MDNode` that don't use all its functionality it might make sense to break it apart again, but until then this makes the code clearer. llvm-svn: 226520
* IR: Return unique_ptr from MDNode::getTemporary()Duncan P. N. Exon Smith2015-01-191-3/+2
| | | | | | | | | | | | Change `MDTuple::getTemporary()` and `MDLocation::getTemporary()` to return (effectively) `std::unique_ptr<T, MDNode::deleteTemporary>`, and clean up call sites. (For now, `DIBuilder` call sites just call `release()` immediately.) There's an accompanying change in each of clang and polly to use the new API. llvm-svn: 226504
* IR: Remove MDNodeFwdDeclDuncan P. N. Exon Smith2015-01-191-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove `MDNodeFwdDecl` (as promised in r226481). Aside from API changes, there's no real functionality change here. `MDNode::getTemporary()` now forwards to `MDTuple::getTemporary()`, which returns a tuple with `isTemporary()` equal to true. The main point is that we can now add temporaries of other `MDNode` subclasses, needed for PR22235 (I introduced `MDNodeFwdDecl` in the first place because I didn't recognize this need, and thought they were only needed to handle forward references). A few things left out of (or highlighted by) this commit: - I've had to remove the (few) uses of `std::unique_ptr<>` to deal with temporaries, since the destructor is no longer public. `getTemporary()` should probably return the equivalent of `std::unique_ptr<T, MDNode::deleteTemporary>`. - `MDLocation::getTemporary()` doesn't exist yet (worse, it actually does exist, but does the wrong thing: `MDNode::getTemporary()` is inherited and returns an `MDTuple`). - `MDNode` now only has one subclass, `UniquableMDNode`, and the distinction between them is actually somewhat confusing. I'll fix those up next. llvm-svn: 226501
* Bring r226038 back.Rafael Espindola2015-01-191-14/+42
| | | | | | | | | | | | | | | | No change in this commit, but clang was changed to also produce trivial comdats when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226467
* Revert r226242 - Revert Revert Don't create new comdats in CodeGenTimur Iskhodzhanov2015-01-161-42/+14
| | | | | | This breaks AddressSanitizer (ninja check-asan) on Windows llvm-svn: 226251
* Revert "Revert Don't create new comdats in CodeGen"Rafael Espindola2015-01-161-14/+42
| | | | | | | | | | | | | | | | | | This reverts commit r226173, adding r226038 back. No change in this commit, but clang was changed to also produce trivial comdats for costructors, destructors and vtables when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226242
* Revert Don't create new comdats in CodeGenTimur Iskhodzhanov2015-01-151-42/+14
| | | | | | It breaks AddressSanitizer on Windows. llvm-svn: 226173
* Don't create new comdats in CodeGen.Rafael Espindola2015-01-141-14/+42
| | | | | | | | | This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226038
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-1/+1
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* AsmParser/Bitcode: Add support for MDLocationDuncan P. N. Exon Smith2015-01-131-0/+14
| | | | | | | | | | | | This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
* IR: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Split `GenericMDNode` into two classes (with more descriptive names). - `UniquableMDNode` will be a common subclass for `MDNode`s that are sometimes uniqued like constants, and sometimes 'distinct'. This class gets the (short-lived) RAUW support and related API. - `MDTuple` is the basic tuple that has always been returned by `MDNode::get()`. This is as opposed to more specific nodes to be added soon, which have additional fields, custom assembly syntax, and extra semantics. This class gets the hash-related logic, since other sublcasses of `UniquableMDNode` may need to hash based on other fields. To keep this diff from getting too big, I've added casts to `MDTuple` that won't really scale as new subclasses of `UniquableMDNode` are added, but I'll clean those up incrementally. (No functionality change intended.) llvm-svn: 225682
* Use the DiagnosticHandler to print diagnostics when reading bitcode.Rafael Espindola2015-01-102-293/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
* Revert "Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLD"Duncan P. N. Exon Smith2015-01-091-1/+1
| | | | | | | | | | | | | | | This reverts commit r225498 (but leaves r225499, which was a worthy cleanup). My plan was to change `DEBUG_LOC` to store the `MDNode` directly rather than its operands (patch was to go out this morning), but on reflection it's not clear that it's strictly better. (I had missed that the current code is unlikely to emit the `MDNode` at all.) Conflicts: lib/Bitcode/Reader/BitcodeReader.cpp (due to r225499) llvm-svn: 225531
* Bitcode: Share logic for last instruction, NFCDuncan P. N. Exon Smith2015-01-091-14/+10
| | | | | | Share logic for getting the last instruction emitted. llvm-svn: 225499
* Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLDDuncan P. N. Exon Smith2015-01-091-1/+1
| | | | | | Prepare to simplify the `DebugLoc` record. llvm-svn: 225498
* IR: Add 'distinct' MDNodes to bitcode and assemblyDuncan P. N. Exon Smith2015-01-081-1/+7
| | | | | | | | | | | | | | | | | | Propagate whether `MDNode`s are 'distinct' through the other types of IR (assembly and bitcode). This adds the `distinct` keyword to assembly. Currently, no one actually calls `MDNode::getDistinct()`, so these nodes only get created for: - self-references, which are never uniqued, and - nodes whose operands are replaced that hit a uniquing collision. The concept of distinct nodes is still not quite first-class, since distinct-ness doesn't yet survive across `MapMetadata()`. Part of PR22111. llvm-svn: 225474
* 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
OpenPOWER on IntegriCloud