summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer/ValueEnumerator.h
Commit message (Collapse)AuthorAgeFilesLines
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith2015-04-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* uselistorder: Thread bit through ValueEnumeratorDuncan P. N. Exon Smith2015-04-141-1/+4
| | | | | | | | 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
* BitcodeWriter: Refactor common computation of bits required for a type index.David Blaikie2015-02-251-0/+1
| | | | | | Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
* Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for ↵Aaron Ballman2015-02-151-2/+2
| | | | | | requiring the macro. NFC; LLVM edition. llvm-svn: 229340
* IR: Assembly and bitcode for GenericDebugNodeDuncan P. N. Exon Smith2015-02-031-0/+2
| | | | llvm-svn: 228041
* Bitcode: Add ValueEnumerator::getMetadataOrNullID(), NFCDuncan P. N. Exon Smith2015-01-201-1/+8
| | | | llvm-svn: 226533
* AsmParser/Bitcode: Add support for MDLocationDuncan P. N. Exon Smith2015-01-131-0/+2
| | | | | | | | | | | | 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
* Bitcode: Simplify emission of METADATA_BLOCKDuncan P. N. Exon Smith2015-01-121-0/+3
| | | | | | | | | | Refactor logic so that we know up-front whether to open a block and whether we need an MDString abbreviation. This is almost NFC, but will start emitting `MDString` abbreviations when the first record is not an `MDString`. llvm-svn: 225712
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Pass a reference to ValueEnumerator.Rafael Espindola2014-11-171-2/+2
| | | | | | NFC. This will just make it easier to use std::unique_ptr in a caller. llvm-svn: 222170
* IR: Remove dead code in metadata bitcode writing, NFCDuncan P. N. Exon Smith2014-10-211-2/+2
| | | | | | | No one cares how many uses each metadata value has, so don't bother counting. llvm-svn: 220337
* 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
* Bitcode: Serialize (and recover) use-list orderDuncan P. N. Exon Smith2014-07-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* IR: Add COMDATs to the IRDavid Majnemer2014-06-271-0/+9
| | | | | | | | | | | | | | | | 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
* Revert "Give internal classes hidden visibility."Benjamin Kramer2013-09-111-1/+1
| | | | | | | It works with clang, but GCC has different rules so we can't make all of those hidden. This reverts commit r190534. llvm-svn: 190536
* Give internal classes hidden visibility.Benjamin Kramer2013-09-111-1/+1
| | | | | | Worth 100k on a linux/x86_64 Release+Asserts clang. llvm-svn: 190534
* Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper2013-07-111-1/+1
| | | | | | size. llvm-svn: 186098
* Use the AttributeSet as the 'key' to the map instead of the 'raw' pointer.Bill Wendling2013-02-121-3/+3
| | | | llvm-svn: 174950
* Rename AttributeSets to AttributeGroups so that it's more meaningful.Bill Wendling2013-02-111-9/+9
| | | | llvm-svn: 174911
* Add support for attribute groups in the value enumerator.Bill Wendling2013-02-101-0/+14
| | | | | | | Attribute groups are essentially all AttributeSets which are used by the program. Enumerate them here. llvm-svn: 174844
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-2/+2
| | | | | | single attribute in the future. llvm-svn: 170502
* s/AttrListPtr/AttributeSet/g to better label what this class is going to be ↵Bill Wendling2012-12-071-5/+5
| | | | | | in the near future. llvm-svn: 169651
* Code Custodian:Joe Abbey2012-11-251-10/+10
| | | | | | | | - Widespread trailing space removal - A dash of OCD spacing to block align enums - joined a line that probably needed 80 cols a while back llvm-svn: 168566
* Use LLVM_DELETED_FUNCTION in place of 'DO NOT IMPLEMENT' comments.Craig Topper2012-09-151-3/+3
| | | | llvm-svn: 163974
* ValueEnumerator - debug dump().Chad Rosier2011-12-071-0/+4
| | | | llvm-svn: 146070
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-4/+4
| | | | llvm-svn: 135375
* Land the long talked about "type system rewrite" patch. ThisChris Lattner2011-07-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
* Revert name change from r132533. Lower case naming was intended per style ↵Chad Rosier2011-06-031-3/+3
| | | | | | guidelines. llvm-svn: 132555
* Whitespace and other cleanup. Functionallity unchanged.Chad Rosier2011-06-031-3/+3
| | | | llvm-svn: 132533
* Do a topological sort of the types before writing them out.Rafael Espindola2011-04-061-2/+2
| | | | | | This takes the linking of libxul on linux from 6m54.931s to 5m39.840s. llvm-svn: 129009
* Extend function-local metadata to be usable as attachments.Dan Gohman2010-08-241-0/+7
| | | | llvm-svn: 111895
* Make NamedMDNode not be a subclass of Value, and simplify the interfaceDan Gohman2010-07-211-1/+1
| | | | | | for creating and populating NamedMDNodes. llvm-svn: 109061
* Speedup bitcode writer. Do not walk all values for all functions to emit ↵Devang Patel2010-06-021-1/+6
| | | | | | function local metadata. In one testcase, probably worst case scenario, the 70x speed up is seen. llvm-svn: 105360
* Remove MetadataBase class because it is not adding significant value.Devang Patel2010-01-221-1/+1
| | | | llvm-svn: 94243
* Simplify code that chooses when to enumerate function-local metadata operandsVictor Hernandez2010-01-141-3/+3
| | | | llvm-svn: 93446
* Avoid modifying ValueEnumerator's MD ValueList by choosing which ↵Victor Hernandez2010-01-141-1/+0
| | | | | | function-local MD to write based on the function currently being written llvm-svn: 93441
* Enumerate function-local metadata (and its types and operands) only during ↵Victor Hernandez2010-01-131-3/+4
| | | | | | function-incorporation, global metadata continues to be enumerated during creation of ValueEnumerator llvm-svn: 93338
* Derive NamedMDNode from Value.Devang Patel2010-01-091-0/+2
| | | | llvm-svn: 93032
* Use separate namespace for named metadata.Devang Patel2010-01-071-0/+2
| | | | llvm-svn: 92931
* bitcode writer support for blockaddress.Chris Lattner2009-10-281-0/+9
| | | | llvm-svn: 85376
* Write and read metadata attachments.Devang Patel2009-09-181-2/+10
| | | | llvm-svn: 82259
* Use separate ValueList for metadata.Devang Patel2009-08-041-7/+8
| | | | | | This fixes PR4666. llvm-svn: 78056
* Don't remove aggregate-typed module level constants before encoding functionsNick Lewycky2009-06-121-5/+0
| | | | | | since functions may contain aggregate constants too. llvm-svn: 73220
* Large mechanical patch.Devang Patel2008-09-251-10/+10
| | | | | | | | | | | | | | | s/ParamAttr/Attribute/g s/PAList/AttrList/g s/FnAttributeWithIndex/AttributeWithIndex/g s/FnAttr/Attribute/g This sets the stage - to implement function notes as function attributes and - to distinguish between function attributes and return value attributes. This requires corresponding changes in llvm-gcc and clang. llvm-svn: 56622
* s/ParameterAttributes/Attributes/gDevang Patel2008-09-231-1/+1
| | | | llvm-svn: 56513
* Reimplement the parameter attributes support, phase #1. hilights:Chris Lattner2008-03-121-8/+9
| | | | | | | | | | | | | | | | | | | | | | | 1. There is now a "PAListPtr" class, which is a smart pointer around the underlying uniqued parameter attribute list object, and manages its refcount. It is now impossible to mess up the refcount. 2. PAListPtr is now the main interface to the underlying object, and the underlying object is now completely opaque. 3. Implementation details like SmallVector and FoldingSet are now no longer part of the interface. 4. You can create a PAListPtr with an arbitrary sequence of ParamAttrsWithIndex's, no need to make a SmallVector of a specific size (you can just use an array or scalar or vector if you wish). 5. All the client code that had to check for a null pointer before dereferencing the pointer is simplified to just access the PAListPtr directly. 6. The interfaces for adding attrs to a list and removing them is a bit simpler. Phase #2 will rename some stuff (e.g. PAListPtr) and do other less invasive changes. llvm-svn: 48289
* Remove attribution from file headers, per discussion on llvmdev.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45418
OpenPOWER on IntegriCloud