summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
...
* LiveInterval: Add support to track liveness of subregisters.Matthias Braun2014-12-102-1/+133
| | | | | | This code adds the required data structures. Algorithms to compute it follow. llvm-svn: 223877
* LiveInterval: Add a 'covers' operation to LiveRange.Matthias Braun2014-12-101-0/+6
| | | | llvm-svn: 223876
* LiveInterval: Add const version of LiveRange::advanceTo().Matthias Braun2014-12-101-0/+8
| | | | llvm-svn: 223875
* Add function that translates subregister lane masks to other subregs.Matthias Braun2014-12-101-0/+15
| | | | | | | This works like the composeSubRegisterIndices() function but transforms a subregister lane mask instead of a subregister index. llvm-svn: 223874
* Let tablegen compute maximum lanemask for regs/regclasses.Matthias Braun2014-12-101-0/+8
| | | | | | | | Let tablegen compute the combination of subregister lanemasks for all subregisters in a register/register class. This is preparation for further work subregister allocation llvm-svn: 223873
* Extend some comments around GCModuleInfo, GCFunctionInfo, & GCStrategyPhilip Reames2014-12-102-5/+8
| | | | | | Nothing particularly interesting here, just documenting the way the code currently works before I start changing it... llvm-svn: 223866
* Remove the Module pointer from GCStrategy and GCMetadataPrinterPhilip Reames2014-12-092-9/+2
| | | | | | | | | | | | | | | | In the current implementation, GCStrategy is a part of the ownership structure for the gc metadata which describes a Module. It also contains a reference to the module in question. As a result, GCStrategy instances are essentially Module specific. I plan to transition away from this design. Instead, a GCStrategy will be owned by the LLVMContext. It will be a lightweight policy object which contains no information about the Modules or Functions involved, but can be easily reached given a Function. The first step in this transition is to remove the direct Module reference from GCStrategy. This also requires removing the single user of this reference, the GCMetadataPrinter hierarchy. In theory, this will allow the lifetime of the printers to be scoped to the LLVMContext as well, but in practice, I'm not actually changing that. (Yet?) An alternate design would have been to move the direct Module reference into the GCMetadataPrinter and change the keying of the owning maps to explicitly key off both GCStrategy and Module. I'm open to doing it that way instead, but didn't see much value in preserving the per Module association for GCMetadataPrinters. The next change in this sequence will be to start unwinding the intertwined ownership between GCStrategy, GCModuleInfo, and GCFunctionInfo. Differential Revision: http://reviews.llvm.org/D6566 llvm-svn: 223859
* IR: Metadata: Detect an RAUW recursionDuncan P. N. Exon Smith2014-12-091-2/+3
| | | | | | | | | | 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-1/+3
| | | | | | | | | | | 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
* Return ErrorOr<std::unique_ptr<Archive>> form getAsArchive.Rafael Espindola2014-12-091-1/+1
| | | | | | This is the same return type of Archive::create. llvm-svn: 223827
* Try fixing MSVC build after r223802Hans Wennborg2014-12-092-3/+0
| | | | | | | | | | | LLVM_EXPLICIT is only supported by recent version of MSVC, and it seems the not-so-recent versions get confused about the operator bool() when tryint to resolve operator== calls. This removed the operator bool()'s since they don't seem to be used anyway. llvm-svn: 223824
* Rename createIRObjectFile to just create.Rafael Espindola2014-12-091-2/+2
| | | | | | | It is a static method of IRObjectFile, so having to use IRObjectFile::createIRObjectFile was redundant. llvm-svn: 223822
* Fix an MSVC failure from r223802Duncan P. N. Exon Smith2014-12-091-0/+6
| | | | llvm-svn: 223820
* Fix another GCC build failure from r223802Duncan P. N. Exon Smith2014-12-091-0/+1
| | | | llvm-svn: 223810
* Cleanup PatternMatch. NFC.Juergen Ributzka2014-12-091-395/+330
| | | | | | | Tidy up the code a little by using 'auto' when the type is obvious, doxify the comments, and clang-format the file. llvm-svn: 223807
* Adding a new option to CMake to disable C++ atexit on llvm-shlib.Chris Bieneman2014-12-091-0/+3
| | | | | | | | | | | | | | | | | Summary: This is desirable for WebKit and other clients of the llvm-shlib because C++ exit time destructors have a tendency to crash when invoked from multi-threaded applications. Ideally this option will be temporary, because the ideal fix is to just not have exit time destructors. Reviewers: chapuni, ributzka Reviewed By: ributzka Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6572 llvm-svn: 223805
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-0919-211/+1022
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CGP] Rewrite pattern match for splitBranchCondition to work with Values ↵Juergen Ributzka2014-12-091-7/+0
| | | | | | | | | instead. Rewrite the pattern match code to work also with Values instead with Instructions only. Also remove the no longer need matcher (m_Instruction). llvm-svn: 223797
* Revert "Move function to obtain branch weights into the BranchInst class. NFC."Juergen Ributzka2014-12-091-4/+0
| | | | | | This reverts commit r223784 and copies the 'ExtractBranchMetadata' to CodeGenPrepare. llvm-svn: 223795
* Add more pattern matchers for compares, instructions, and BinaryOperators. NFC.Juergen Ributzka2014-12-091-4/+50
| | | | | | Add a few more matchers to make the code in the next commit more compact. llvm-svn: 223785
* Move function to obtain branch weights into the BranchInst class. NFC.Juergen Ributzka2014-12-091-0/+4
| | | | | | Make this function available to other parts of LLVM. llvm-svn: 223784
* Move method out of line to make buildbot happy.Rafael Espindola2014-12-091-1/+1
| | | | llvm-svn: 223781
* Don't lookup an object symbol name in the module.Rafael Espindola2014-12-091-1/+5
| | | | | | | | | | | Instead, walk the obj symbol list in parallel to find the GV. This shouldn't change anything on ELF where global symbols are not mangled, but it is a step toward supporting other object formats. Gold itself is ELF only, but bfd ld supports COFF and the logic in the gold plugin could be reused on lld. llvm-svn: 223780
* InstrProf: An intrinsic and lowering for instrumentation based profilingJustin Bogner2014-12-085-0/+47
| | | | | | | | | | | | | | | | | | | | | Introduce the ``llvm.instrprof_increment`` intrinsic and the ``-instrprof`` pass. These provide the infrastructure for writing counters for profiling, as in clang's ``-fprofile-instr-generate``. The implementation of the instrprof pass is ported directly out of the CodeGenPGO classes in clang, and with the followup in clang that rips that code out to use these new intrinsics this ends up being NFC. Doing the instrumentation this way opens some doors in terms of improving the counter performance. For example, this will make it simple to experiment with alternate lowering strategies, and allows us to try handling profiling specially in some optimizations if we want to. Finally, this drastically simplifies the frontend and puts all of the lowering logic in one place. llvm-svn: 223672
* Turn some DenseMaps that are only used for set operations into DenseSets.Benjamin Kramer2014-12-061-2/+1
| | | | | | DenseSet has better memory efficiency now. llvm-svn: 223589
* Make the DenseMap bucket type configurable and use a smaller bucket for ↵Benjamin Kramer2014-12-063-107/+132
| | | | | | | | | | | | | | DenseSet. DenseSet used to be implemented as DenseMap<Key, char>, which usually doubled the memory footprint of the map. Now we use a compressed set so the second element uses no memory at all. This required some surgery on DenseMap as all accesses to the bucket now have to go through methods; this should have no impact on the behavior of DenseMap though. The new default bucket type for DenseMap is a slightly extended std::pair as we expose it through DenseMap's iterator and don't want to break any existing users. llvm-svn: 223588
* Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-1/+2
| | | | | | | | DenseMaps." This reapplies r223478 with a fix for 32 bit targets. llvm-svn: 223586
* Avoid angle brackets in comment. [-Wdocumentation-html]NAKAMURA Takumi2014-12-061-1/+1
| | | | llvm-svn: 223576
* Fix typoMatt Arsenault2014-12-061-4/+5
| | | | llvm-svn: 223572
* Revert "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-2/+1
| | | | | | | | | 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-1/+2
| | | | | | | | 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
* Update TargetTriple format info.Chad Rosier2014-12-051-0/+1
| | | | | | Phabricator revision: http://reviews.llvm.org/D6543 llvm-svn: 223473
* Fix typos in llvm/IR/Module.hChad Rosier2014-12-051-2/+2
| | | | | | Phabricator revision: http://reviews.llvm.org/D6535 llvm-svn: 223472
* ADT: Remove GetStringMapEntryFromValue()Duncan P. N. Exon Smith2014-12-051-13/+0
| | | | | | | It relies on undefined behaviour, since `StringMapEntry<>` is not a standard layout type. There are no users anyway. llvm-svn: 223439
* IR: Stop relying on GetStringMapEntryFromValue()Duncan P. N. Exon Smith2014-12-051-1/+2
| | | | | | It relies on undefined behaviour. llvm-svn: 223438
* Revert "Fix UBSan report in StringMap implementation."Alexey Samsonov2014-12-041-1/+4
| | | | | | | This reverts commit r223402. Some bots fail with -Winvalid-offsetof warning. llvm-svn: 223407
* Fix UBSan report in StringMap implementation.Alexey Samsonov2014-12-041-4/+1
| | | | | | Use offsetof() instead of a member access within null pointer. llvm-svn: 223402
* Remove dead code. NFC.Rafael Espindola2014-12-041-100/+2
| | | | | | This interface was added 2 years ago but users never developed. llvm-svn: 223368
* Use size_type in the interface exposed by SmallVector.Rafael Espindola2014-12-041-9/+9
| | | | | | | This matches std::vector and should avoid unnecessary masking to 32 bits when calling them on o 64 bits system. llvm-svn: 223365
* Masked Load / Store Intrinsics - the CodeGen part.Elena Demikhovsky2014-12-048-4/+128
| | | | | | | | | | | | | | | | | | I'm recommiting the codegen part of the patch. The vectorizer part will be send to review again. Masked Vector Load and Store Intrinsics. Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores. Added SDNodes for masked operations and lowering patterns for X86 code generator. Examples: <16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask) declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask) Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch. http://reviews.llvm.org/D6191 llvm-svn: 223348
* Add mach-o LC_RPATH support to llvm-objdumpJean-Daniel Dupas2014-12-042-0/+8
| | | | | | | | | | Summary: Add rpath load command support in Mach-O object and update llvm-objdump to use it. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6512 llvm-svn: 223343
* Allow target to specify prefix for labelsMatt Arsenault2014-12-041-0/+5
| | | | | | | | Use the MCAsmInfo instead of the DataLayout, and allow specifying a custom prefix for labels specifically. HSAIL requires that labels begin with @, but global symbols with &. llvm-svn: 223323
* Split the set of identified struct types into opaque and non-opaque ones.Rafael Espindola2014-12-031-2/+41
| | | | | | | | | | | | | | | | | | | The non-opaque part can be structurally uniqued. To keep this to just a hash lookup, we don't try to unique cyclic types. Also change the type mapping algorithm to be optimistic about a type not being recursive and only create a new type when proven to be wrong. This is not as strong as trying to speculate that we can keep the source type, but is simpler (no speculation to revert) and more powerfull than what we had before (we don't copy non-recursive types at least). I initially wrote this to try to replace the name based type merging. It is not strong enough to replace it, but is is a useful addition. With this patch the number of named struct types is a clang lto bootstrap goes from 49674 to 15986. llvm-svn: 223278
* Change the name to be in style.Roman Divacky2014-12-031-1/+1
| | | | llvm-svn: 223255
* Ask the module for its the identified types.Rafael Espindola2014-12-032-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When lazy reading a module, the types used in a function will not be visible to a TypeFinder until the body is read. This patch fixes that by asking the module for its identified struct types. If a materializer is present, the module asks it. If not, it uses a TypeFinder. This fixes pr21374. I will be the first to say that this is ugly, but it was the best I could find. Some of the options I looked at: * Asking the LLVMContext. This could be made to work for gold, but not currently for ld64. ld64 will load multiple modules into a single context before merging them. This causes us to see types from future merges. Unfortunately, MappedTypes is not just a cache when it comes to opaque types. Once the mapping has been made, we have to remember it for as long as the key may be used. This would mean moving MappedTypes to the Linker class and having to drop the Linker::LinkModules static methods, which are visible from C. * Adding an option to ignore function bodies in the TypeFinder. This would fix the PR by picking the worst result. It would work, but unfortunately we are currently quite dependent on the upfront type merging. I will try to reduce our dependency, but it is not clear that we will be able to get rid of it for now. The only clean solution I could think of is making the Module own the types. This would have other advantages, but it is a much bigger change. I will propose it, but it is nice to have this fixed while that is discussed. With the gold plugin, this patch takes the number of types in the LTO clang binary from 52817 to 49669. llvm-svn: 223215
* ADT: Rename argument in emplace_back_implDuncan P. N. Exon Smith2014-12-031-2/+2
| | | | | | | Rename a functor argument in r223201 from `emplace` to `construct` to reduce confusion. llvm-svn: 223212
* ADT: Add SmallVector<>::emplace_back(): fixupDuncan P. N. Exon Smith2014-12-031-1/+1
| | | | | | | Add missing `void` return type from `!LLVM_HAS_VARIADIC_TEMPLATES` case in r223201. llvm-svn: 223202
* ADT: Add SmallVector<>::emplace_back()Duncan P. N. Exon Smith2014-12-031-0/+45
| | | | llvm-svn: 223201
* GCRelocateOperands: Try to appease msc17.NAKAMURA Takumi2014-12-031-2/+3
| | | | llvm-svn: 223192
* Prologue supportPeter Collingbourne2014-12-031-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud