summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Metadata.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* IR: Reuse `getImpl()` for `getDistinct()`, NFCDuncan P. N. Exon Smith2015-01-191-48/+54
| | | | | | | | Merge `getDistinct()`'s implementation with those of `get()` and `getIfExists()` for both `MDTuple` and `MDLocation`. This will make it easier to scale to supporting temporaries. llvm-svn: 226497
* IR: Simplify MDNode::setOperand(), NFCDuncan P. N. Exon Smith2015-01-191-5/+1
| | | | llvm-svn: 226492
* IR: Simplify handleChangedOperand() fast path, NFCDuncan P. N. Exon Smith2015-01-191-3/+1
| | | | | | | Use `isUniqued()` instead of `isStoredDistinctInContext()`, and remove an assertion that won't be valid once temporaries are merged back in. llvm-svn: 226491
* IR: Remove direct comparisons against Metadata::Storage, NFCDuncan P. N. Exon Smith2015-01-191-3/+3
| | | | llvm-svn: 226490
* IR: Assert that resolve() is only called on uniqued nodes, NFCDuncan P. N. Exon Smith2015-01-191-1/+3
| | | | | | | | | Add an assertion in `UniquableMDNode::resolve()` to prevent temporaries from being resolved (once they're merged back in). Needed to shuffle order of `resolve()` and `storeDistinctInContext()` to prevent it from firing. llvm-svn: 226489
* IR: Unify code for MDNode::isResolved(), NFCDuncan P. N. Exon Smith2015-01-191-6/+0
| | | | | | | | | | Unify the definitions of `MDNode::isResolved()` and `UniquableMDNode::isResolved()`. Previously, `UniquableMDNode` could answer this question more efficiently, but now that RAUW support has been unified with `MDNodeFwdDecl`, `MDNode` doesn't need any casts to figure out the answer. llvm-svn: 226485
* IR: Store RAUW support and Context in the same pointer, NFCDuncan P. N. Exon Smith2015-01-191-5/+9
| | | | | | | | | | | | | | Add an `LLVMContext &` to `ReplaceableMetadataImpl`, create a class that either holds a reference to an `LLVMContext` or owns a `ReplaceableMetadataImpl`, and use the new class in `MDNode`. - This saves a pointer in `UniquableMDNode` at the cost of a pointer in `ValueAsMetadata` (which didn't used to store the `LLVMContext`). There are far more of the former. - Unifies RAUW support between `MDNodeFwdDecl` (which is going away, see r226481) and `UniquableMDNode`. llvm-svn: 226484
* IR: Add isUniqued() and isTemporary()Duncan P. N. Exon Smith2015-01-191-1/+1
| | | | | | | | Change `MDNode::isDistinct()` to only apply to 'distinct' nodes (not temporaries), and introduce `MDNode::isUniqued()` and `MDNode::isTemporary()` for the other two possibilities. llvm-svn: 226482
* IR: Use an enum to describe Metadata storage, NFCDuncan P. N. Exon Smith2015-01-191-19/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | More clearly describe the type of storage used for `Metadata`. - `Uniqued`: uniqued, stored in the context. - `Distinct`: distinct, stored in the context. - `Temporary`: not owned by anyone. This is the first in a series of commits to fix a design problem with `MDNodeFwdDecl` that I need to solve for PR22235. While `MDNodeFwdDecl` works well as a forward declaration, we use `MDNode::getTemporary()` for more than forward declarations -- we also need to create early versions of nodes (with fields not filled in) that we'll fill out later (see `DIBuilder::finalize()` and `CGDebugInfo::finalize()` for examples). This was a blind spot I had when I introduced `MDNodeFwdDecl` (which David Blaikie (indirectly) highlighted in an unrelated review [1]). [1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150112/252381.html In general, we need `MDTuple::getTemporary()` to give a temporary tuple (like `MDNodeFwdDecl`), `MDLocation::getTemporary()` to give a temporary location, and (the problem at hand) `GenericDebugMDNode::getTemporary()` to give a temporary generic debug node. So I need to fold the idea of "temporary" nodes back into `UniquableMDNode`. (More commits to follow as I refactor.) llvm-svn: 226481
* IR: Allow 16-bits for column infoDuncan P. N. Exon Smith2015-01-161-3/+3
| | | | | | Raise the limit for column information from 8 bits to 16 bits. llvm-svn: 226291
* IR: Fix a use-after-free in RAUWDuncan P. N. Exon Smith2015-01-141-0/+5
| | | | | | | | | | Happened pretty commonly during `LLVMContext` teardown when `clang -g` hit an error. This fixes the use-after-free. Next I'll clean up teardown so that it's not RAUW'ing when metadata-tracked values are deleted (only really causes a problem if the graph is mid-construction when teardown starts, but it's still unnecessary work). llvm-svn: 226029
* IR: Add MDLocation classDuncan P. N. Exon Smith2015-01-131-3/+90
| | | | | | | | | | | Add a new subclass of `UniquableMDNode`, `MDLocation`. This will be the IR version of `DebugLoc` and `DILocation`. The goal is to rename this to `DILocation` once the IR classes supersede the `DI`-prefixed wrappers. This isn't used anywhere yet. Part of PR21433. llvm-svn: 225824
* IR: Remove an invalid assertion when replacing resolved operandsDuncan P. N. Exon Smith2015-01-131-3/+5
| | | | | | | | | This adds back the testcase from r225738, and adds to it. Looks like we need both sides for now (the assertion was incorrect both ways, and although it seemed reasonable (when written correctly) it wasn't particularly important). llvm-svn: 225745
* Revert "IR: Fix an inverted assertion when replacing resolved operands"Duncan P. N. Exon Smith2015-01-131-1/+1
| | | | | | | | This reverts commit r225738. Maybe the assertion is just plain wrong, but this version fails on WAY more bots. I'll make sure both ways work in a follow-up but I want to get bots green in the meantime. llvm-svn: 225742
* IR: Fix an inverted assertion when replacing resolved operandsDuncan P. N. Exon Smith2015-01-131-1/+1
| | | | | | | Add a unit test, since this bug was only exposed by clang tests. Thanks to Rafael for tracking this down! llvm-svn: 225738
* IR: Prepare for a new UniquableMDNode subclass, NFCDuncan P. N. Exon Smith2015-01-121-11/+56
| | | | | | | | Add generic dispatch for the parts of `UniquableMDNode` that cast to `MDTuple`. This makes adding other subclasses (like PR21433's `MDLocation`) easier. llvm-svn: 225697
* IR: Stop erasing MDNodes from uniquing sets during teardownDuncan P. N. Exon Smith2015-01-121-12/+0
| | | | | | | | | | Stop erasing `MDNode`s from the uniquing sets in `LLVMContextImpl` during teardown (in particular, during `UniquableMDNode::~UniquableMDNode()`). Although it's currently feasible, there isn't any clear benefit and it may not be feasible for other subclasses (which don't explicitly store the lookup hash). llvm-svn: 225696
* IR: Move creation logic to MDNodeFwdDecl, NFCDuncan P. N. Exon Smith2015-01-121-6/+2
| | | | | | | Same as with `MDTuple`, factor out a `friend MDNode` by moving creation logic to the concrete subclass. llvm-svn: 225690
* IR: Move creation logic down to MDTuple, NFCDuncan P. N. Exon Smith2015-01-121-6/+6
| | | | | | | | | Move creation logic for `MDTuple`s down where it belongs. Once there are a few more subclasses, these functions really won't make much sense here (the `friend` relationship was already awkward). For now, leave the `MDNode` versions around, but have it forward down. llvm-svn: 225685
* IR: Push storeDistinctInContext() down to UniquableMDNode, NFCDuncan P. N. Exon Smith2015-01-121-1/+1
| | | | llvm-svn: 225683
* IR: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-121-36/+39
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* IR: Invert logic to simplify control flow, NFCDuncan P. N. Exon Smith2015-01-121-8/+5
| | | | llvm-svn: 225670
* IR: Separate out decrementUnresolvedOperandCount(), NFCDuncan P. N. Exon Smith2015-01-121-6/+8
| | | | llvm-svn: 225667
* IR: Prevent handleChangedOperand() recursionDuncan P. N. Exon Smith2015-01-121-8/+6
| | | | | | | | | | | Instead of returning early on `handleChangedOperand()` recursion (finally identified (and test added) in r225657), prevent it upfront by releasing operands before RAUW. Aside from massively different program flow, there should be no functionality change ;). llvm-svn: 225665
* IR: Add test for handleChangedOperand() recursionDuncan P. N. Exon Smith2015-01-121-2/+0
| | | | | | | Turns out this can happen. Remove the `FIXME` and add a testcase that crashes without the extra logic. llvm-svn: 225657
* IR: Separate out recalculateHash(), NFCDuncan P. N. Exon Smith2015-01-121-11/+13
| | | | llvm-svn: 225655
* IR: Separate out helper: resolveAfterOperandChange(), NFCDuncan P. N. Exon Smith2015-01-121-15/+18
| | | | llvm-svn: 225654
* IR: Use SubclassData32 directly, NFCDuncan P. N. Exon Smith2015-01-121-8/+11
| | | | | | | Simplify some logic by accessing `SubclassData32` directly instead of relying on API. llvm-svn: 225653
* IR: Don't allow operands to become unresolvedDuncan P. N. Exon Smith2015-01-121-6/+10
| | | | | | | Operands shouldn't change from being resolved to unresolved during graph construction. Simplify the logic based on that assumption. llvm-svn: 225649
* IR: Remove redundant comment, NFCDuncan P. N. Exon Smith2015-01-121-1/+0
| | | | llvm-svn: 225648
* IR: Simplify code, NFCDuncan P. N. Exon Smith2015-01-121-1/+1
| | | | llvm-svn: 225647
* IR: Simplify replaceOperandWith(), NFCDuncan P. N. Exon Smith2015-01-121-4/+3
| | | | | | | | This will call `handleChangedOperand()` less frequently, but in that case (i.e., `isStoredDistinctInContext()`) it has identical logic to here. llvm-svn: 225643
* IR: Remove redundant calls to MDNode::setHash(), NFCDuncan P. N. Exon Smith2015-01-121-2/+0
| | | | | | `storeDistinctInContext()` already calls `setHash(0)`. llvm-svn: 225642
* IR: Add MDNode::getDistinct()Duncan P. N. Exon Smith2015-01-071-2/+12
| | | | | | | | | | Allow distinct `MDNode`s to be explicitly created. There's no way (yet) of representing their distinctness in assembly/bitcode, however, so this still isn't first-class. Part of PR22111. llvm-svn: 225406
* Linker: Don't use MDNode::replaceOperandWith()Duncan P. N. Exon Smith2015-01-071-0/+5
| | | | | | | | | | | `MDNode::replaceOperandWith()` changes all instances of metadata. Stop using it when linking module flags, since (due to uniquing) the flag values could be used by other metadata. Instead, use new API `NamedMDNode::setOperand()` to update the reference directly. llvm-svn: 225397
* IR: Don't drop MDNode uniquing on null operandsDuncan P. N. Exon Smith2015-01-051-7/+2
| | | | | | | | | | Now that `LLVMContextImpl` can call `MDNode::dropAllReferences()` to prevent teardown madness, stop dropping uniquing just because an operand drops to null. Part of PR21532. llvm-svn: 225223
* IR: Prune arguments to ValueAsMetadata::ValueAsMetadata()Duncan P. N. Exon Smith2015-01-051-2/+2
| | | | | | `LLVMContext` isn't actually used. llvm-svn: 225200
* The leak detector is dead, long live asan and valgrind.Rafael Espindola2014-12-221-3/+0
| | | | | | | In resent times asan and valgrind have found way more memory management bugs in llvm than the special purpose leak detector. llvm-svn: 224703
* Delete debugging cruft that crept in with r223802.Nick Lewycky2014-12-171-3/+0
| | | | llvm-svn: 224407
* IR: Don't track nullptr on metadata RAUWDuncan P. N. Exon Smith2014-12-121-1/+2
| | | | | | | | | | | | | | | | | The RAUW support in `Metadata` supports going to `nullptr` specifically to handle values being deleted, causing `ValueAsMetadata` to be deleted. Fix the case where the reference is from a `TrackingMDRef` (as opposed to an `MDOperand` or a `MetadataAsValue`). This is surprisingly rare -- metadata tracked by `TrackingMDRef` going to null -- but it came up in an openSUSE bootstrap during inlining. The tracking ref was held by the `ValueMap` because it was referencing a local, the basic block containing the local became dead after it had been merged in, and when the local was deleted, the tracking ref asserted in an `isa`. llvm-svn: 224146
* IR: Move call to dropAllReferences() to MDNode subclassesDuncan P. N. Exon Smith2014-12-101-0/+1
| | | | | | | Don't call `dropAllReferences()` from `MDNode::~MDNode()`, call it directly from `~MDNodeFwdDecl()` and `~GenericMDNode()`. llvm-svn: 223904
* IR: Fix memory corruption in MDNode new/deleteDuncan P. N. Exon Smith2014-12-091-4/+8
| | | | | | | | | | | | | | | There were two major problems with `MDNode` memory management. 1. `MDNode::operator new()` called a placement array constructor for `MDOperand`. What? Each operand needs to be placed individually. 2. `MDNode::operator delete()` failed to destruct the `MDOperand`s at all. Frankly it's hard to understand how this worked locally, how this survived an LTO bootstrap, or how it worked on most of the bots. llvm-svn: 223858
* IR: Metadata: Detect an RAUW recursionDuncan P. N. Exon Smith2014-12-091-0/+9
| | | | | | | | | | Speculatively handle a recursion in `GenericMDNode::handleChangedOperand()`. I'm hoping this fixes the failing hexagon bot [1]. [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13434 llvm-svn: 223849
* IR: Metadata/Value split: RAUW in a deterministic orderDuncan P. N. Exon Smith2014-12-091-21/+38
| | | | | | | | | | | RAUW in a deterministic order to try to recover the hexagon bot [1], whose tests started failing once my GCC fixes were in for r223802. Otherwise, I'm not sure why tests would fail there and not here. [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13426 llvm-svn: 223829
* Fix a GCC build failure from r223802Duncan P. N. Exon Smith2014-12-091-1/+2
| | | | llvm-svn: 223806
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-313/+550
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Revert r223618 behaviour of MDNode::concatenate()Duncan P. N. Exon Smith2014-12-071-12/+23
| | | | | | | | | | | | | r223618 including special handling of `MDNode::intersect()`: if the first operand is a self-reference with the same operands you're trying to return, return it instead. Reuse that handling in `MDNode::concatenate()` in the hopes that it fixes a polly test that seems to rely on the old behaviour [1]. [1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25167 llvm-svn: 223619
* IR: Drop uniquing for self-referencing MDNodesDuncan P. N. Exon Smith2014-12-071-1/+15
| | | | | | | | | | | | | | | It doesn't make sense to unique self-referencing nodes. Drop uniquing for them. Note that `MDNode::intersect()` occasionally returns self-referencing nodes. Previously these would be returned by `MDNode::get()`. I'm not convinced this was intended behaviour -- to me it seems it should return a node whose only operand is the self-reference -- but I don't know much about alias scopes so I'm preserving it for now. This is part of PR21532. llvm-svn: 223618
* IR: Disallow function-local metadata attachmentsDuncan P. N. Exon Smith2014-12-061-0/+2
| | | | | | | | 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-48/+27
| | | | | | | | | | 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
OpenPOWER on IntegriCloud