summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/LLVMContextImpl.h
Commit message (Collapse)AuthorAgeFilesLines
* IR: Fix MDType fields from unsigned to uint64_tDuncan P. N. Exon Smith2015-02-191-14/+14
| | | | | | | | | When trying to match the current schema with the new debug info hierarchy, I downgraded `SizeInBits`, `AlignInBits` and `OffsetInBits` to 32-bits (oops!). Caught this while testing my upgrade script to move the hierarchy into place. Bump it back up to 64-bits and update tests. llvm-svn: 229933
* IR: Drop scope from MDTemplateParameterDuncan P. N. Exon Smith2015-02-191-19/+11
| | | | | | | | | | Follow-up to r229740, which removed `DITemplate*::getContext()` after my upgrade script revealed that scopes are always `nullptr` for template parameters. This is the other shoe: drop `scope:` from `MDTemplateParameter` and its two subclasses. (Note: a bitcode upgrade would be pointless, since the hierarchy hasn't been moved into place.) llvm-svn: 229791
* IR: Remove unnecessary fields from MDTemplateParameterDuncan P. N. Exon Smith2015-02-101-25/+10
| | | | | | | | I noticed this fields were never used in r228607, but I neglected to propagate that into `MDTemplateParameter` until now. This really should have been done before commit in r228640; sorry for the churn. llvm-svn: 228652
* IR: Add specialized debug info metadata nodesDuncan P. N. Exon Smith2015-02-101-0/+575
| | | | | | | | | | | | | | | Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
* IR: Rename 'operator ==()' to 'isKeyOf()', NFCDuncan P. N. Exon Smith2015-02-051-4/+4
| | | | | | `isKeyOf()` is a clearer name than overloading `operator==()`. llvm-svn: 228242
* IR: Reduce boilerplate in DenseMapInfo overrides, NFCDuncan P. N. Exon Smith2015-02-041-91/+63
| | | | | | | Minimize the boilerplate required for the `MDNode` subclass `DenseMapInfo<>` overrides in `LLVMContextImpl`. llvm-svn: 228212
* IR: Define MDNode uniquing sets automatically, NFCDuncan P. N. Exon Smith2015-02-041-3/+2
| | | | llvm-svn: 228200
* 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
* Revert GCStrategy ownership changesPhilip Reames2015-01-261-11/+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
* IR: Change GenericDwarfNode::getHeader() to StringRefDuncan P. N. Exon Smith2015-01-221-2/+2
| | | | | | | Simplify the API to use a `StringRef` directly rather than exposing the `MDString` bits underneath. llvm-svn: 226876
* IR: DwarfNode => DebugNode, NFCDuncan P. N. Exon Smith2015-01-221-14/+14
| | | | | | | | | These things are potentially used for non-DWARF data (see the discussion in PR22235), so take the `Dwarf` out of the name. Since the new name gives fewer clues, update the doxygen to properly describe what they are. llvm-svn: 226874
* Remove dead leak detector parts that fell out of use in r224703.Benjamin Kramer2015-01-221-4/+0
| | | | llvm-svn: 226867
* [llvm link] Destroy ConstantArrays in LLVMContext if they are not used.Manman Ren2015-01-201-0/+3
| | | | | | | | | | | | | | 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: Introduce GenericDwarfNodeDuncan P. N. Exon Smith2015-01-201-8/+53
| | | | | | | | | | | | 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-23/+48
| | | | | | Make the MDTuple operand hashing logic reusable. llvm-svn: 226519
* Move ownership of GCStrategy objects to LLVMContextPhilip Reames2015-01-161-0/+12
| | | | | | | | | | | | 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: Add MDLocation classDuncan P. N. Exon Smith2015-01-131-0/+43
| | | | | | | | | | | 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: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-121-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | 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-59/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Turn some DenseMaps that are only used for set operations into DenseSets.Benjamin Kramer2014-12-061-5/+5
| | | | | | DenseSet has better memory efficiency now. llvm-svn: 223589
* Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-39/+22
| | | | | | | | DenseMaps." This reapplies r223478 with a fix for 32 bit targets. llvm-svn: 223586
* Reformat.NAKAMURA Takumi2014-12-061-26/+18
| | | | llvm-svn: 223580
* Revert "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-15/+46
| | | | | | | | | DenseMaps." Somehow made DenseMap probe on forever on 32 bit machines. This reverts commit r223478. llvm-svn: 223546
* LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP DenseMaps.Benjamin Kramer2014-12-051-46/+15
| | | | | | | | Required some APInt massaging to get proper empty/tombstone values. Apart from making the code a bit simpler this also reduces the bucket size of the ConstantInt map from 32 to 24 bytes. llvm-svn: 223478
* Prologue supportPeter Collingbourne2014-12-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "unique_ptrify LLVMContextImpl::CAZConstants"David Blaikie2014-11-251-4/+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/+4
| | | | llvm-svn: 222714
* Add params() to FunctionType. NFC.Rafael Espindola2014-11-211-4/+3
| | | | | | While at it, also use makeArrayRef in elements(). llvm-svn: 222556
* Add and use a helper elements() to StructType. NFC.Rafael Espindola2014-11-211-3/+2
| | | | llvm-svn: 222553
* IR: Split MDNode into GenericMDNode and MDNodeFwdDeclDuncan P. N. Exon Smith2014-11-181-13/+13
| | | | | | | | | | | | | | | | | | | 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-16/+46
| | | | | | | | | | | | | | | | | | 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
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-1/+1
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Duncan P. N. Exon Smith2014-08-191-8/+6
| | | | | | | | | | | | 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-6/+8
| | | | | | 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: Replace uses of ConstantAggrUniqueMap with ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-4/+4
| | | | | | | Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same way, change the aggregates to use the new one. llvm-svn: 215959
* IR: Rewrite ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-4/+2
| | | | | | | | | | | | | | | | | | | | | 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
* 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
* Remove LLVMContextImpl::optimizationRemarkEnabledFor.Diego Novillo2014-05-221-9/+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-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+3
| | | | | | | | | | | | | | | | | | | | | 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-15/+1
| | | | | | | Revert the current implementation and C API. New implementation and C APIs are in the works. llvm-svn: 208904
* [PM] Add pass run listeners to the pass manager.Juergen Ributzka2014-04-281-1/+15
| | | | | | | | | | | | | | | | | | 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
* [C++] Use 'nullptr'.Craig Topper2014-04-281-2/+2
| | | | llvm-svn: 207394
* Add -pass-remarks flag to 'opt'.Diego Novillo2014-04-081-0/+4
| | | | | | | | | | | | | | | | | | | | | Summary: This adds support in 'opt' to filter pass remarks emitted by optimization passes. A new flag -pass-remarks specifies which passes should emit a diagnostic when LLVMContext::emitOptimizationRemark is invoked. This will allow the front end to simply pass along the regular expression from its own -Rpass flag when launching the backend. Depends on D3227. Reviewers: qcolombet CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3291 llvm-svn: 205775
* [C++11] Add 'override' keyword to IR library.Craig Topper2014-03-051-3/+3
| | | | llvm-svn: 202939
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-041-1/+1
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* Pass to emit DWARF path discriminators.Diego Novillo2014-03-031-1/+6
| | | | | | | | | | | | | | | | DWARF discriminators are used to distinguish multiple control flow paths on the same source location. When this happens, instructions across basic block boundaries will share the same debug location. This pass detects this situation and creates a new lexical scope to one of the two instructions. This lexical scope is a child scope of the original and contains a new discriminator value. This discriminator is then picked up from MCObjectStreamer::EmitDwarfLocDirective to be written on the object file. This fixes http://llvm.org/bugs/show_bug.cgi?id=18270. llvm-svn: 202752
OpenPOWER on IntegriCloud