summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* MachineVerifier: Allow physreg use if just a subreg is defined.Matthias Braun2014-12-101-1/+12
| | | | | | | | We can't mark partially undefined registers, so we have to allow reading a register in the machine verifier if just parts of a register are defined. llvm-svn: 223896
* MachineVerifier: Allow LiveInterval segments to end at a partial write.Matthias Braun2014-12-101-2/+10
| | | | | | | | In the subregister liveness tracking case we do not create implicit reads on partial register writes anymore, still we need to produce a new SSA value for partial writes so the live segment has to end. llvm-svn: 223895
* VirtRegMap: Improve block live-in info if subregister liveness is available.Matthias Braun2014-12-101-9/+32
| | | | llvm-svn: 223894
* VirtRegMap: No implicit defs/uses for super registers with subreg liveness ↵Matthias Braun2014-12-102-5/+33
| | | | | | | | | | | | | tracking. Adding the implicit defs/uses to the superregisters is semantically questionable but was not dangerous before as the register allocator never assigned the same register to two overlapping LiveIntervals even when the actually live subregisters do not overlap. With subregister liveness tracking enabled this does actually happen and leads to subsequent bugs if we don't stop adding the superregister defs/uses. llvm-svn: 223892
* LiveRegMatrix: Respect subregister liveness when allocating registers.Matthias Braun2014-12-101-14/+49
| | | | llvm-svn: 223891
* LiveIntervalUnion: Allow specification of liverange when unifying/extracting.Matthias Braun2014-12-101-9/+9
| | | | | | This allows it to add subregister ranges into the union. llvm-svn: 223890
* RegisterCoalescer: Preserve subregister liveranges.Matthias Braun2014-12-101-121/+559
| | | | llvm-svn: 223888
* LiveInterval: Add removeEmptySubRanges().Matthias Braun2014-12-101-0/+17
| | | | llvm-svn: 223887
* LiveIntervalAnalysis: Add subregister aware variants pruneValue().Matthias Braun2014-12-102-12/+22
| | | | llvm-svn: 223886
* Add a flag to enable/disable subregister liveness.Matthias Braun2014-12-103-3/+13
| | | | llvm-svn: 223884
* LiveIntervalAnalysis: Adapt repairIntervalsInRange() to subregister liveness.Matthias Braun2014-12-101-77/+92
| | | | llvm-svn: 223883
* LiveRangeEdit: Adapt eliminateDeadDef() to subregister liveness.Matthias Braun2014-12-101-1/+9
| | | | llvm-svn: 223882
* LiveIntervalAnalysis: Adapt handleMove() to subregister ranges.Matthias Braun2014-12-101-16/+30
| | | | llvm-svn: 223881
* LiveIntervalAnalysis: Update SubRanges in shrinkToUses().Matthias Braun2014-12-101-75/+146
| | | | llvm-svn: 223880
* LiveIntervalAnalysis: Compute subregister ranges.Matthias Braun2014-12-102-100/+258
| | | | llvm-svn: 223878
* LiveInterval: Add support to track liveness of subregisters.Matthias Braun2014-12-104-31/+113
| | | | | | 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/+21
| | | | llvm-svn: 223876
* AsmParser: Don't crash if a null byte is inside a quoted stringDavid Majnemer2014-12-102-52/+34
| | | | | | | We don't allow Value* to have names which contain null bytes. The AsmParser should reject .ll files that try to do this. llvm-svn: 223869
* [ARM] Combine base-updating/post-incrementing vector load/stores.Ahmed Bougacha2014-12-101-6/+38
| | | | | | | | | | | | | | | | | | We used to only combine intrinsics, and turn them into VLD1_UPD/VST1_UPD when the base pointer is incremented after the load/store. We can do the same thing for generic load/stores. Note that we can only combine the first load/store+adds pair in a sequence (as might be generated for a v16f32 load for instance), because other combines turn the base pointer addition chain (each computing the address of the next load, from the address of the last load) into independent additions (common base pointer + this load's offset). Differential Revision: http://reviews.llvm.org/D6585 llvm-svn: 223862
* Remove the Module pointer from GCStrategy and GCMetadataPrinterPhilip Reames2014-12-095-18/+17
| | | | | | | | | | | | | | | | 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: 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
* AsmParser: Verifier that the contents of a hex integer are hexDavid Majnemer2014-12-091-1/+7
| | | | llvm-svn: 223856
* Rename static functiom "map" to be more descriptive and to avoidKaelyn Takata2014-12-091-5/+5
| | | | | | potential confusion with the std::map type. llvm-svn: 223853
* 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
* Remove redundant variable.Michael Zolotukhin2014-12-091-4/+2
| | | | | | | Tested by adding assert(LoopVectorPreHeader == VecPreheader) on LLVM test suite and SPECs. llvm-svn: 223847
* [Hexagon] [NFC] Cleaning up unused classes.Colin LeMahieu2014-12-091-30/+0
| | | | llvm-svn: 223845
* [ARM] Factor out base-updating VLD/VST combiner function. NFC.Ahmed Bougacha2014-12-091-6/+15
| | | | | | | | | Move the combiner-state check into another function, add a few small comments, and use a more general type in a cast<>. In preparation for a future patch. llvm-svn: 223834
* [ARM] Move the store combiner function down. NFC.Ahmed Bougacha2014-12-091-141/+143
| | | | | | | And flip its final condition. In preparation for a future patch. llvm-svn: 223833
* [ARM] Also support v2f64 vld1/vst1.Ahmed Bougacha2014-12-091-0/+2
| | | | | | | | | It was missing from the VLD1/VST1 handling logic, even though the corresponding instructions exist (same form as v2i64). In preparation for a future patch. llvm-svn: 223832
* 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
* Return ErrorOr<std::unique_ptr<Archive>> form getAsArchive.Rafael Espindola2014-12-091-14/+10
| | | | | | This is the same return type of Archive::create. llvm-svn: 223827
* Try fixing MSVC build after r223802Hans Wennborg2014-12-091-1/+1
| | | | | | | | | | | 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
* [Hexagon] Fixing broken tests.Colin LeMahieu2014-12-091-1/+2
| | | | llvm-svn: 223823
* Rename createIRObjectFile to just create.Rafael Espindola2014-12-092-4/+4
| | | | | | | It is a static method of IRObjectFile, so having to use IRObjectFile::createIRObjectFile was redundant. llvm-svn: 223822
* [Hexagon] Updating rr/ri 32/64 transfer encodings and adding tests.Colin LeMahieu2014-12-099-178/+194
| | | | llvm-svn: 223821
* [FastISel][AArch64] Fix a missing nullptr check in 'computeAddress'.Juergen Ributzka2014-12-091-1/+1
| | | | | | | | | The load/store value type is currently not available when lowering the memcpy intrinsic. Add the missing nullptr check to support this in 'computeAddress'. Fixes rdar://problem/19178947. llvm-svn: 223818
* [Hexagon] Adding word combine dot-new form and replacing old combine opcode.Colin LeMahieu2014-12-095-80/+51
| | | | llvm-svn: 223815
* Revert r223764 which taught instcombine about integer-based elment extractionChandler Carruth2014-12-091-349/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | patterns. This is causing Clang to miscompile itself for 32-bit x86 somehow, and likely also on ARM and PPC. I really don't know how, but reverting now that I've confirmed this is actually the culprit. I have a reproduction as well and so should be able to restore this shortly. This reverts commit r223764. Original commit log follows: Teach instcombine to canonicalize "element extraction" from a load of an integer and "element insertion" into a store of an integer into actual element extraction, element insertion, and vector loads and stores. Previously various parts of LLVM (including instcombine itself) would introduce integer loads and stores into the code as a way of opaquely loading and storing "bits". In some cases (such as a memcpy of std::complex<float> object) we will eventually end up using those bits in non-integer types. In order for SROA to effectively promote the allocas involved, it splits these "store a bag of bits" integer loads and stores up into the constituent parts. However, for non-alloca loads and tsores which remain, it uses integer math to recombine the values into a large integer to load or store. All of this would be "fine", except that it forces LLVM to go through integer math to combine and split up values. While this makes perfect sense for integers (and in fact is critical for bitfields to end up lowering efficiently) it is *terrible* for non-integer types, especially floating point types. We have a much more canonical way of representing the act of concatenating the bits of two SSA values in LLVM: a vector and insertelement. This patch teaching InstCombine to use this representation. With this patch applied, LLVM will no longer introduce integer math into the critical path of every loop over std::complex<float> operations such as those that make up the hot path of ... oh, most HPC code, Eigen, and any other heavy linear algebra library. For the record, I looked *extensively* at fixing this in other parts of the compiler, but it just doesn't work: - We really do want to canonicalize memcpy and other bit-motion to integer loads and stores. SSA values are tremendously more powerful than "copy" intrinsics. Not doing this regresses massive amounts of LLVM's scalar optimizer. - We really do need to split up integer loads and stores of this form in SROA or every memcpy of a trivially copyable struct will prevent SSA formation of the members of that struct. It essentially turns off SROA. - The closest alternative is to actually split the loads and stores when partitioning with SROA, but this has all of the downsides historically discussed of splitting up loads and stores -- the wide-store information is fundamentally lost. We would also see performance regressions for bitfield-heavy code and other places where the integers aren't really intended to be split without seemingly arbitrary logic to treat integers totally differently. - We *can* effectively fix this in instcombine, so it isn't that hard of a choice to make IMO. llvm-svn: 223813
* AsmParser: Don't crash on short hex constants for fp128 typesDavid Majnemer2014-12-091-5/+7
| | | | | | | If we see 0xL01, treat it like 0xL00000000000000000000000000000001 instead of crashing. llvm-svn: 223811
* Remove unneeded curly braces.Frederic Riss2014-12-091-4/+2
| | | | llvm-svn: 223809
* Reorder the code to avoid inserting at the beginning of a vector.Frederic Riss2014-12-091-1/+1
| | | | | | As per dblaikie suggestion, thanks\! llvm-svn: 223808
* Fix a GCC build failure from r223802Duncan P. N. Exon Smith2014-12-091-1/+2
| | | | llvm-svn: 223806
* [AVX512] Added lowering for VBROADCASTSS/SD instructions.Robert Khasanov2014-12-092-1/+56
| | | | | | | Lowering patterns were written through avx512_broadcast_pat multiclass as pattern generates VBROADCAST and COPY_TO_REGCLASS nodes. Added lowering tests. llvm-svn: 223804
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-0960-1691/+2185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* AsmParser: Don't crash on malformed attribute groupsDavid Majnemer2014-12-091-1/+3
| | | | | | This fixes PR21785. llvm-svn: 223801
* [Hexagon] Updating predicate register transfers and adding tstbit to allow ↵Colin LeMahieu2014-12-095-27/+74
| | | | | | select selection. Updating ll tests with predicate transfers that previously had nop encodings. llvm-svn: 223800
* Correctly handle complex locations expressions in replaceDbgDeclareForAlloca()Frederic Riss2014-12-091-2/+2
| | | | | | | | | | | | | | | | replaceDbgDeclareForAlloca() replaces an alloca by a value storing the address of what was the alloca. If there is a dbg.declare corresponding to that alloca, we need to lower it to a dbg.value describing the additional dereference operation to be performed to get to the underlying variable. This is done by adding a DW_OP_deref to the complex location part of the location description. This deref was added to the end of the operation list, which is wrong. The expression applies to what is described by the dbg.{declare,value}, and as we are changing this, we need to apply the DW_OP_deref as the first operation in the list. Part of the fix for rdar://19162268. llvm-svn: 223799
* [CGP] Rewrite pattern match for splitBranchCondition to work with Values ↵Juergen Ributzka2014-12-091-7/+10
| | | | | | | | | 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-093-28/+49
| | | | | | This reverts commit r223784 and copies the 'ExtractBranchMetadata' to CodeGenPrepare. llvm-svn: 223795
* [PowerPC 4/4] Enable little-endian support for VSX.Bill Schmidt2014-12-091-7/+0
| | | | | | | | With the foregoing three patches, VSX instructions can be used for little endian. This patch removes the restriction that prevented this, and re-enables the test cases from the first three patches. llvm-svn: 223792
OpenPOWER on IntegriCloud