summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/LLVMContextImpl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko2017-06-191-20/+10
| | | | llvm-svn: 305755
* [IR] De-virtualize ~Value to save a vptrReid Kleckner2017-05-181-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implements PR889 Removing the virtual table pointer from Value saves 1% of RSS when doing LTO of llc on Linux. The impact on time was positive, but too noisy to conclusively say that performance improved. Here is a link to the spreadsheet with the original data: https://docs.google.com/spreadsheets/d/1F4FHir0qYnV0MEp2sYYp_BuvnJgWlWPhWOwZ6LbW7W4/edit?usp=sharing This change makes it invalid to directly delete a Value, User, or Instruction pointer. Instead, such code can be rewritten to a null check and a call Value::deleteValue(). Value objects tend to have their lifetimes managed through iplist, so for the most part, this isn't a big deal. However, there are some places where LLVM deletes values, and those places had to be migrated to deleteValue. I have also created llvm::unique_value, which has a custom deleter, so it can be used in place of std::unique_ptr<Value>. I had to add the "DerivedUser" Deleter escape hatch for MemorySSA, which derives from User outside of lib/IR. Code in IR cannot include MemorySSA headers or call the MemoryAccess object destructors without introducing a circular dependency, so we need some level of indirection. Unfortunately, no class derived from User may have any virtual methods, because adding a virtual method would break User::getHungOffOperands(), which assumes that it can find the use list immediately prior to the User object. I've added a static_assert to the appropriate OperandTraits templates to help people avoid this trap. Reviewers: chandlerc, mehdi_amini, pete, dberlin, george.burgess.iv Reviewed By: chandlerc Subscribers: krytarowski, eraman, george.burgess.iv, mzolotukhin, Prazek, nlewycky, hans, inglorion, pcc, tejohnson, dberlin, llvm-commits Differential Revision: https://reviews.llvm.org/D31261 llvm-svn: 303362
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* Use unique_ptr in LLVMContextImpl's constant maps.Justin Lebar2016-10-101-5/+6
| | | | | | | | | | Reviewers: timshen Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25419 llvm-svn: 283767
* [OptRemark,LDist] RFC: Add hotness attributeAdam Nemet2016-07-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first set of changes implementing the RFC from http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334 This is a cross-sectional patch; rather than implementing the hotness attribute for all optimization remarks and all passes in a patch set, it implements it for the 'missed-optimization' remark for Loop Distribution. My goal is to shake out the design issues before scaling it up to other types and passes. Hotness is computed as an integer as the multiplication of the block frequency with the function entry count. It's only printed in opt currently since clang prints the diagnostic fields directly. E.g.: remark: /tmp/t.c:3:3: loop not distributed: use -Rpass-analysis=loop-distribute for more info (hotness: 300) A new API added is similar to emitOptimizationRemarkMissed. The difference is that it additionally takes a code region that the diagnostic corresponds to. From this, hotness is computed using BFI. The new API is exposed via an analysis pass so that it can be made dependent on LazyBFI. (Thanks to Hal for the analysis pass idea.) This feature can all be enabled by setDiagnosticHotnessRequested in the LLVM context. If this is off, LazyBFI is not calculated (D22141) so there should be no overhead. A new command-line option is added to turn this on in opt. My plan is to switch all user of emitOptimizationRemark* to use this module instead. Reviewers: hfinkel Subscribers: rcox2, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D21771 llvm-svn: 275583
* Apply clang-tidy's modernize-loop-convert to most of lib/IR.Benjamin Kramer2016-06-261-4/+3
| | | | | | Only minor manual fixes. No functionality change intended. llvm-svn: 273813
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-0/+18
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-18/+0
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-0/+18
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* IR: Use DenseSet instead of DenseMap for ConstantUniqueMap; NFCDuncan P. N. Exon Smith2016-04-061-32/+10
| | | | | | | | | | | | | | | | | | Use a DenseSet instead of a DenseMap for constants in LLVMContextImpl. Last time I looked at this was some time before r223588, when DenseSet<V> had no advantage over DenseMap<V,char>. After r223588, there's a 50% memory savings. This is all mechanical. There were little bits of missing API from DenseSet so I added the trivial implementations: - iterator::operator++(int) - template <class LookupKeyT> insert_as(ValueTy, LookupKeyT) There should be no functionality change, just reduced memory consumption (this wasn't on a profile or anything; just a cleanup I stumbled on). llvm-svn: 265577
* IR: Stop explicitly clearing the MDStringCacheDuncan P. N. Exon Smith2016-04-061-3/+0
| | | | | | | The MDStringCache doesn't need to be explicitly cleared before destruction. The destructor handles it at least as efficiently. llvm-svn: 265576
* [IR] Manage TheNoneToken with a std::unique_ptrDavid Majnemer2015-11-161-1/+0
| | | | | | Hopefully, this will make the sanitizer build bots happy. llvm-svn: 253248
* [IR] Add support for empty tokensDavid Majnemer2015-11-111-0/+1
| | | | | | | | | | | | | | When working with tokens, it is often the case that one has instructions which consume a token and produce a new token. Currently, we have no mechanism to represent an initial token state. Instead, we can create a notional "empty token" by inventing a new constant which captures the semantics we would like. This new constant is called ConstantTokenNone and is written textually as "token none". Differential Revision: http://reviews.llvm.org/D14581 llvm-svn: 252811
* [IR] Add operand bundles to CallInst and InvokeInst.Sanjoy Das2015-09-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change teaches `CallInst`s and `InvokeInst`s to maintain a set of operand bundles as part of its operands. `CallInst`s and `InvokeInst`s with operand bundles co-allocate some space before their `Use` array to hold meta information about which of its operands are part of an operand bundle. The strings corresponding to the bundle tags are interned into `LLVMContextImpl::BundleTagCache` This change does not include any parsing / bitcode support. That's the next change. Depends on D12455. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: MatzeB, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D12456 llvm-svn: 248527
* [IR] Add token typesDavid Majnemer2015-08-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-031-3/+3
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-2/+2
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-2/+2
| | | | | | | | | | | | | 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
* Add the i128 builtin type to LLVM.Kit Barton2015-04-171-1/+2
| | | | | | | | | | | The i128 type is needed as a builtin type in order to support the v1i128 vector type. The PowerPC ABI requires that the i128 and v1i128 types are handled differently when passed as parameters to functions (i128 is passed in pairs of GPRs, v1i128 is passed in a single vector register). http://reviews.llvm.org/D8564 llvm-svn: 235196
* Revert GCStrategy ownership changesPhilip Reames2015-01-261-23/+0
| | | | | | | | | | | | This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways. The bugs were: - Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely. - GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times. Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/. llvm-svn: 227109
* Remove dead leak detector parts that fell out of use in r224703.Benjamin Kramer2015-01-221-2/+1
| | | | llvm-svn: 226867
* [llvm link] Destroy ConstantArrays in LLVMContext if they are not used.Manman Ren2015-01-201-0/+22
| | | | | | | | | | | | | | ConstantArrays constructed during linking can cause quadratic memory explosion. An example is the ConstantArrays constructed when linking in GlobalVariables with appending linkage. Releasing all unused constants can cause a 20% LTO compile-time slowdown for a large application. So this commit releases unused ConstantArrays only. rdar://19040716. It reduces memory footprint from 20+G to 6+G. llvm-svn: 226592
* IR: Delete GenericDwarfNode during teardownDuncan P. N. Exon Smith2015-01-201-6/+6
| | | | | | | | | | Fix a leak in `LLVMContextImpl` teardown that the leak sanitizer tracked down [1]. I've just switched to automatic dispatch here (since I'll inevitably forget again with the next class). [1]: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/811/steps/check-llvm%20asan/logs/stdio llvm-svn: 226536
* IR: Introduce GenericDwarfNodeDuncan P. N. Exon Smith2015-01-201-3/+3
| | | | | | | | | | | | As part of PR22235, introduce `DwarfNode` and `GenericDwarfNode`. The former is a metadata node with a DWARF tag. The latter matches our current (generic) schema of a header with string (and stringified integer) data and an arbitrary number of operands. This doesn't move it into place yet; that change will require a large number of testcase updates. llvm-svn: 226529
* 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: Extract MDNodeOpsKey, NFCDuncan P. N. Exon Smith2015-01-191-0/+34
| | | | | | Make the MDTuple operand hashing logic reusable. llvm-svn: 226519
* Move ownership of GCStrategy objects to LLVMContextPhilip Reames2015-01-161-0/+24
| | | | | | | | | | | | Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions. Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance. In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.) Differential Revision: http://reviews.llvm.org/D6811 llvm-svn: 226311
* IR: Drop metadata references more aggressively during teardownDuncan P. N. Exon Smith2015-01-141-16/+24
| | | | | | | | | | | | | | | | | | Sometimes teardown happens before the debug info graph is complete (e.g., when clang throws an error). In that case, `MDNode`s will still have RAUW, so deleting constants that the `MDNode`s point at will be relatively expensive -- it'll cause re-uniquing all up the chain (what I've been referring to as "teardown madness"). So, drop references *before* deleting constants. We need to drop a few more references now: the metadata side of the metadata/value bridges needs to be dropped off the cliff along with the rest of it (previously, the bridges were cleaned before we did anything with the `MDNode`s). There's no real functionality change here -- state before and after `LLVMContextImpl::~LLVMContextImpl()` is unchanged -- so no testcase. llvm-svn: 226044
* IR: Add MDLocation classDuncan P. N. Exon Smith2015-01-131-0/+4
| | | | | | | | | | | 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: Prepare for a new UniquableMDNode subclass, NFCDuncan P. N. Exon Smith2015-01-121-1/+1
| | | | | | | | 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-10/+8
| | | | | | | | | | 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: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-121-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "unique_ptrify LLVMContextImpl::CAZConstants"David Blaikie2014-11-251-1/+1
| | | | | | | | Missed the complexities of how these elements are destroyed. This reverts commit r222714. llvm-svn: 222715
* unique_ptrify LLVMContextImpl::CAZConstantsDavid Blaikie2014-11-251-1/+1
| | | | llvm-svn: 222714
* IR: Move MDNode operands from the back to the frontDuncan P. N. Exon Smith2014-11-181-2/+4
| | | | | | | | | | | | | | | | | Having the operands at the back prevents subclasses from safely adding fields. Move them to the front. Instead of replicating the custom `malloc()`, `free()` and `DestroyFlag` logic that was there before, overload `new` and `delete`. I added calls to a new `GenericMDNode::dropAllReferences()` in `LLVMContextImpl::~LLVMContextImpl()`. There's a maze of callbacks happening during teardown, and this resolves them before we enter the destructors. Part of PR21532. llvm-svn: 222211
* IR: Split MDNode into GenericMDNode and MDNodeFwdDeclDuncan P. N. Exon Smith2014-11-181-4/+3
| | | | | | | | | | | | | | | | | | | Split `MDNode` into two classes: - `GenericMDNode`, which is uniquable (and for now, always starts uniqued). Once `Metadata` is split from the `Value` hierarchy, this class will lose the ability to RAUW itself. - `MDNodeFwdDecl`, which is used for the "temporary" interface, is never uniqued, and isn't managed by `LLVMContext` at all. I've left most of the guts in `MDNode` for now, but I'll incrementally move things to the right places (or delete the functionality, as appropriate). Part of PR21532. llvm-svn: 222205
* IR: Simplify uniquing for MDNodeDuncan P. N. Exon Smith2014-11-171-3/+1
| | | | | | | | | | | | | | | | | | Change uniquing from a `FoldingSet` to a `DenseSet` with custom `DenseMapInfo`. Unfortunately, this doesn't save any memory, since `DenseSet<T>` is a simple wrapper for `DenseMap<T, char>`, but I'll come back to fix that later. I used the name `GenericDenseMapInfo` to the custom `DenseMapInfo` since I'll be splitting `MDNode` into two classes soon: `MDNodeFwdDecl` for temporaries, and `GenericMDNode` for everything else. I also added a non-debug-info reduced version of a type-uniquing test that started failing on an earlier draft of this patch. Part of PR21532. llvm-svn: 222191
* IR: Rewrite uniquing and creation of MDStringDuncan P. N. Exon Smith2014-11-141-1/+1
| | | | | | | | | | Stop using `Value::getName()` to get the string behind an `MDString`. Switch to `StringMapEntry<MDString>` so that we can find the string by its coallocation. This is part of PR21532. llvm-svn: 221960
* LTO: Ignore disabled diagnostic remarksDuncan P. N. Exon Smith2014-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | r206400 and r209442 added remarks that are disabled by default. However, if a diagnostic handler is registered, the remarks are sent unfiltered to the handler. This is the right behaviour for clang, since it has its own filters. However, the diagnostic handler exposed in the LTO API receives only the severity and message. It doesn't have the information to filter by pass name. For LTO, disabled remarks should be filtered by the producer. I've changed `LLVMContext::setDiagnosticHandler()` to take a `bool` argument indicating whether to respect the built-in filters. This defaults to `false`, so other consumers don't have a behaviour change, but `LTOCodeGenerator::setDiagnosticHandler()` sets it to `true`. To make this behaviour testable, I added a `-use-diagnostic-handler` command-line option to `llvm-lto`. This fixes PR21108. llvm-svn: 218784
* Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Duncan P. N. Exon Smith2014-08-191-1/+1
| | | | | | | | | | | | r215957 This reverts commit r215981, which reverted the above commits because MSVC std::equal asserts on nullptr iterators, and thes commits introduced an `ArrayRef::equals()` on empty ArrayRefs. ArrayRef was changed not to use std::equal in r215986. llvm-svn: 215987
* Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Aaron Ballman2014-08-191-1/+1
| | | | | | r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic). llvm-svn: 215981
* IR: Rewrite ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | Rewrite `ConstantUniqueMap` to be more similar to `ConstantAggrUniqueMap`. - Use a `DenseMap` with custom MapInfo instead of a `std::map` with linear lookups and deletion. - Don't waste memory explicitly storing (heavyweight) keys. Only `ConstantExpr` and `InlineAsm` actually use this data structure, so I also updated them to use it. This code cleanup is a precursor to reducing RAUW traffic on `ConstantExpr` -- I felt badly adding a new (linear) call to `ConstantUniqueMap::FindExistingKey`, so this designs away the concern. A follow-up commit will transition the users of `ConstantAggrUniqueMap` over. llvm-svn: 215957
* Remove LLVMContextImpl::optimizationRemarkEnabledFor.Diego Novillo2014-05-221-77/+0
| | | | | | | | | | | | | | | | Summary: This patch moves the handling of -pass-remarks* over to lib/DiagnosticInfo.cpp. This allows the removal of the optimizationRemarkEnabledFor functions from LLVMContextImpl, as they're not needed anymore. Reviewers: qcolombet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D3878 llvm-svn: 209453
* Add support for missed and analysis optimization remarks.Diego Novillo2014-05-221-18/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds two new diagnostics: -pass-remarks-missed and -pass-remarks-analysis. They take the same values as -pass-remarks but are intended to be triggered in different contexts. -pass-remarks-missed is used by LLVMContext::emitOptimizationRemarkMissed, which passes call when they tried to apply a transformation but couldn't. -pass-remarks-analysis is used by LLVMContext::emitOptimizationRemarkAnalysis, which passes call when they want to inform the user about analysis results. The patch also: 1- Adds support in the inliner for the two new remarks and a test case. 2- Moves emitOptimizationRemark* functions to the llvm namespace. 3- Adds an LLVMContext argument instead of making them member functions of LLVMContext. Reviewers: qcolombet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D3682 llvm-svn: 209442
* Add C API for thread yielding callback.Juergen Ributzka2014-05-161-0/+2
| | | | | | | | | | | | | | | | | | | | | Sometimes a LLVM compilation may take more time then a client would like to wait for. The problem is that it is not possible to safely suspend the LLVM thread from the outside. When the timing is bad it might be possible that the LLVM thread holds a global mutex and this would block any progress in any other thread. This commit adds a new yield callback function that can be registered with a context. LLVM will try to yield by calling this callback function, but there is no guaranteed frequency. LLVM will only do so if it can guarantee that suspending the thread won't block any forward progress in other LLVM contexts in the same process. Once the client receives the call back it can suspend the thread safely and resume it at another time. Related to <rdar://problem/16728690> llvm-svn: 208945
* Revert "[PM] Add pass run listeners to the pass manager."Juergen Ributzka2014-05-151-26/+0
| | | | | | | Revert the current implementation and C API. New implementation and C APIs are in the works. llvm-svn: 208904
* Do not make -pass-remarks additive.Diego Novillo2014-05-061-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When I initially introduced -pass-remarks, I thought it would be a neat idea to make it additive. So, if one used it as: $ llc -pass-remarks=inliner --pass-remarks=loop.* the compiler would build the regular expression '(inliner)|(loop.*)'. The more I think about it, the more I regret it. This is not how other flags work. The standard semantics are right-to-left overrides. This is how clang interprets -Rpass. And I think the two should be compatible in this respect. Reviewers: qcolombet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D3614 llvm-svn: 208122
* [PM] Add pass run listeners to the pass manager.Juergen Ributzka2014-04-281-0/+26
| | | | | | | | | | | | | | | | | | This commit provides the necessary C/C++ APIs and infastructure to enable fine- grain progress report and safe suspension points after each pass in the pass manager. Clients can provide a callback function to the pass manager to call after each pass. This can be used in a variety of ways (progress report, dumping of IR between passes, safe suspension of threads, etc). The run listener list is maintained in the LLVMContext, which allows a multi- threaded client to be only informed for it's own thread. This of course assumes that the client created a LLVMContext for each thread. This fixes <rdar://problem/16728690> llvm-svn: 207430
* Simplify destruction of Modules in LLVContextImpl.David Blaikie2014-04-211-6/+5
| | | | | | | | | | | | | | | | | | | | This avoids copying the container by simply deleting until empty. While I'd rather move to a stricter ownership semantic (unique_ptr), SmallPtrSet can't cope with unique_ptr and the ownership semantics here are a bit incestuous (Module sort of owns itself, but sort of doesn't (if the LLVMContext is destroyed before the Module, then it deregisters itself from the context... )). Ideally Modules would be given to the context, or possibly an emplace-like function to construct them there. Modules then shouldn't be destroyed by LLVM API clients, but by interacting with the owner (LLVMContext) directly (but even then, passing a Module* to LLVMContext doesn't provide an easy way to destroy the Module, since the set would be over unique_ptrs and you'd need a heterogenous lookup function which SmallPtrSet doesn't have either). llvm-svn: 206794
OpenPOWER on IntegriCloud