summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* When the inline spiller rematerializes an instruction, take the debug ↵Wolfgang Pieb2016-08-161-1/+7
| | | | | | | | | | | | location from the instruction that immediately follows the rematerialization point. Patch by Andrea DiBiagio. Differential Revision: http://reviews.llvm.org/D23539 llvm-svn: 278822
* [AArch64][GlobalISel] Select G_MUL.Ahmed Bougacha2016-08-161-0/+4
| | | | llvm-svn: 278810
* [Pipeliner] Fix an asssert due to invalid Phi in the epilogBrendon Cahoon2016-08-161-2/+1
| | | | | | | | | | | | The pipeliner was generating an invalid Phi name for an operand in the epilog block, which caused an assert in the live variable analysis pass. The fix is to the code that generates new Phis in the epilog block. In this case, there is an existing Phi that needs to be reused rather than creating a new Phi instruction. Differential Revision: https://reviews.llvm.org/D23513 llvm-svn: 278805
* [AArch64][GlobalISel] Select p0 G_FRAME_INDEX.Ahmed Bougacha2016-08-161-2/+2
| | | | | | And mark it as legal. llvm-svn: 278802
* [x86] Refactor a PowerPC specific ctlz/srl transformation (NFC).Pierre Gousseau2016-08-161-0/+25
| | | | | | | | Following the discussion on D22038, this refactors a PowerPC specific setcc -> srl(ctlz) transformation so it can be used by other targets. Differential Revision: https://reviews.llvm.org/D23445 llvm-svn: 278799
* [ADT] Change PostOrderIterator to use NodeRef. NFC.Tim Shen2016-08-151-3/+4
| | | | | | | | | | Reviewers: dblaikie Subscribers: mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D23522 llvm-svn: 278752
* Fix typo in lowering for fp128 ueq.Eli Friedman2016-08-151-1/+1
| | | | | | | | Regression from r259791. Differential Revision: https://reviews.llvm.org/D23374 llvm-svn: 278750
* GlobalISel: support loads and stores of strange types.Tim Northover2016-08-152-11/+15
| | | | | | | Before we mischaracterized structs and i1 types as a scalar with size 0 in various ways. llvm-svn: 278744
* Local variables whose address is taken and passed on to a call are described Wolfgang Pieb2016-08-152-4/+33
| | | | | | | | | | | in debug info using their stack slots instead of as an indirection of param reg + 0 offset. This is done by detecting FrameIndexSDNodes in SelectionDAG and generating FrameIndexDbgValues for them. This ultimately generates DBG_VALUEs with stack location operands. Differential Revision: http://reviews.llvm.org/D23283 llvm-svn: 278703
* MachineLoop: add methods findLoopControlBlock and findLoopPreheaderSjoerd Meijer2016-08-151-0/+45
| | | | | | | | | | | This adds two new utility functions findLoopControlBlock and findLoopPreheader to MachineLoop and MachineLoopInfo. These functions are refactored and taken from the Hexagon target as they are target independent; thus this is intendend to be a non-functional change. Differential Revision: https://reviews.llvm.org/D22959 llvm-svn: 278661
* Revert "CodeGen: If Convert blocks that would form a diamond when tail-merged."Diana Picus2016-08-141-351/+65
| | | | | | | | | This reverts commit r278287. This commit broke the clang-cmake-thumbv7-a15-full-sh bot. See https://llvm.org/bugs/show_bug.cgi?id=28949 llvm-svn: 278621
* Revert "Codegen: Don't tail-duplicate blocks with un-analyzable fallthrough."Diana Picus2016-08-141-10/+0
| | | | | | | | | This reverts commit r278288. r278287 broke the clang-cmake-thumbv7-a15-full-sh bot. Revert this so we can get to r278287. llvm-svn: 278620
* Minor comment fix ("generate" --> "generates").Justin Lebar2016-08-121-1/+1
| | | | llvm-svn: 278578
* Reapply [BranchFolding] Restrict tail merging loop blocks after MBPHaicheng Wu2016-08-121-9/+23
| | | | | | | | | Fixed a bug in the test case. To fix PR28104, this patch restricts tail merging to blocks that belong to the same loop after MBP. llvm-svn: 278575
* Revert "[BranchFolding] Restrict tail merging loop blocks after MBP"Haicheng Wu2016-08-121-23/+9
| | | | | | This reverts commit r278463 because it hits the bot. llvm-svn: 278484
* ADT: Remove all ilist_iterator => pointer casts, NFCDuncan P. N. Exon Smith2016-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove all ilist_iterator to pointer casts. There were two reasons for casts: - Checking for an uninitialized (i.e., null) iterator. I added MachineInstrBundleIterator::isValid() to check for that case. - Comparing an iterator against the underlying pointer value while avoiding converting the pointer value to an iterator. This is occasionally necessary in MachineInstrBundleIterator, since there is an assertion in the constructors that the underlying MachineInstr is not bundled (but we don't care about that if we're just checking for pointer equality). To support the latter case, I rewrote the == and != operators for ilist_iterator and MachineInstrBundleIterator. - The implicit constructors now use enable_if to exclude const-iterator => non-const-iterator conversions from overload resolution (previously it was a compiler error on instantiation, now it's SFINAE). - The == and != operators are now global (friends), and are not templated. - MachineInstrBundleIterator has overloads to compare against both const_pointer and const_reference. This avoids the implicit conversions to MachineInstrBundleIterator that assert, instead just checking the address (and I added unit tests to confirm this). Notably, the only remaining uses of ilist_iterator::getNodePtrUnchecked are in ilist.h, and no code outside of ilist*.h directly relies on this UB end-iterator-to-pointer conversion anymore. It's still needed for ilist_*sentinel_traits, but I'll clean that up soon. llvm-svn: 278478
* Use the range variant of remove_if instead of unpacking begin/endDavid Majnemer2016-08-123-7/+6
| | | | | | No functionality change is intended. llvm-svn: 278475
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-126-26/+16
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* [BranchFolding] Restrict tail merging loop blocks after MBPHaicheng Wu2016-08-121-9/+23
| | | | | | | | | To fix PR28014, this patch restricts tail merging to blocks that belong to the same loop after MBP. Differential Revision: https://reviews.llvm.org/D23191 llvm-svn: 278463
* Use the range variant of find_if instead of unpacking begin/endDavid Majnemer2016-08-121-20/+15
| | | | | | No functionality change is intended. llvm-svn: 278443
* Use the range variant of find instead of unpacking begin/endDavid Majnemer2016-08-1120-40/+30
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278433
* GlobalISel: support 'null' constant in translation.Tim Northover2016-08-111-0/+4
| | | | | | | | It's sharing the integer G_CONSTANT for now since I don't *think* it creates any ambiguity (even on weird archs). If that turns out wrong we can create a G_PTRCONSTANT or something. llvm-svn: 278423
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-117-18/+15
| | | | | | No functionality change is intended. llvm-svn: 278417
* CodeGen: Avoid dereferencing end() in MachineSchedulerDuncan P. N. Exon Smith2016-08-111-2/+3
| | | | | | | | | | | | | | | | Check MachineInstr::isDebugValue for the same instruction as we're calling isSchedBoundary, avoiding the possibility of dereferencing end(). This is a functionality change even when I!=end(). Matthias had a look and agrees this is the right resolution (as opposed to checking for end()). This is triggered by a huge number of tests, but they happen to magically pass right now. I found this because WIP patches for PR26753 convert them into crashes. llvm-svn: 278394
* If-conversion incorrectly calculates liveness of redefined registersKrzysztof Parzyszek2016-08-111-2/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D23207 llvm-svn: 278383
* Improve virtual register handling when computing debug informationDominic Chen2016-08-111-7/+16
| | | | | | | | | | | | Summary: Some backends, like WebAssembly, use virtual registers instead of physical registers. This crashes the DbgValueHistoryCalculator pass, which assumes that all registers are physical. Instead, skip virtual registers when iterating aliases, and assume that they are clobbered. Reviewers: dexonsmith, dschuff, aprantl Subscribers: yurydelendik, llvm-commits, jfb, sunfish Differential Revision: https://reviews.llvm.org/D22590 llvm-svn: 278371
* Make TwoAddressInstructionPass::rescheduleMIBelowKill subreg-awareMichael Kuperstein2016-08-111-14/+25
| | | | | | | | This fixes PR28824. Differential Revision: https://reviews.llvm.org/D23220 llvm-svn: 278370
* Fix some Clang-tidy modernize and Include What You Use warnings.Eugene Zelenko2016-08-111-16/+42
| | | | | | Differential revision: https://reviews.llvm.org/D23291 llvm-svn: 278364
* GlobalISel: clear vreg mapping after translating each functionTim Northover2016-08-111-2/+4
| | | | | | | Otherwise we only materialize (shared) constants in the first function they appear in. This doesn't go well. llvm-svn: 278351
* Remove FIXME about asserting on the end iteratorReid Kleckner2016-08-111-5/+1
| | | | | | | | | After machine block placement, MBBs may not have terminators, and it is appropriate to check for the end iterator here. We can fold the check into the next if, as well. This look is really just looking for BBs that end in CATCHRET. llvm-svn: 278350
* CodeGen: Check for a terminator in llvm::getFuncletMembershipDuncan P. N. Exon Smith2016-08-111-0/+5
| | | | | | | | | | | | Check for an end iterator from MachineBasicBlock::getFirstTerminator in llvm::getFuncletMembership. If this is turned into an assertion, it fires in 48 X86 testcases (for example, CodeGen/X86/regalloc-spill-at-ehpad.ll). Since this is likely a latent bug (shouldn't all basic blocks end with a terminator?) I've filed PR28938. llvm-svn: 278344
* Avoid false dependencies of undef machine operandsMarina Yatsina2016-08-111-0/+53
| | | | | | | | | | | | | | | | | | | | This patch helps avoid false dependencies on undef registers by updating the machine instructions' undef operand to use a register that the instruction is truly dependent on, or use a register with clearance higher than Pref. Pseudo example: loop: xmm0 = ... xmm1 = vcvtsi2sdl eax, xmm0<undef> ... = inst xmm0 jmp loop In this example, selecting xmm0 as the undef register creates false dependency between loop iterations. This false dependency cannot be solved by inserting an xor before vcvtsi2sdl because xmm0 is alive at the point of the vcvtsi2sdl instruction. Selecting a different register instead of xmm0, especially a register that is not used in the loop, will eliminate this problem. Differential Revision: https://reviews.llvm.org/D22466 llvm-svn: 278321
* GlobalISel: support same ConstantExprs as Instructions.Tim Northover2016-08-101-75/+41
| | | | | | | | It's more than just inttoptr, but the others can't be tested until we have support for non-trivial constants (they currently get unavoidably folded to a ConstantInt). llvm-svn: 278303
* GlobalISel: implement simple function calls on AArch64.Tim Northover2016-08-101-4/+17
| | | | | | | We're still limited in the arguments we support, but this at least handles the basic cases. llvm-svn: 278293
* Codegen: Don't tail-duplicate blocks with un-analyzable fallthrough.Kyle Butt2016-08-101-0/+10
| | | | | | | | | | | | If AnalyzeBranch can't analyze a block and it is possible to fallthrough, then duplicating the block doesn't make sense, as only one block can be the layout predecessor for the un-analyzable fallthrough. Submitted wit a test case, but NOTE: the test case doesn't currently fail. However, the test case fails with D20505 and would have saved me some time debugging. llvm-svn: 278288
* CodeGen: If Convert blocks that would form a diamond when tail-merged.Kyle Butt2016-08-101-65/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following function currently relies on tail-merging for if conversion to succeed. The common tail of cond_true and cond_false is extracted, and this then forms a diamond pattern that can be successfully if converted. If this block does not get extracted, either because tail-merging is disabled or the threshold is higher, we should still recognize this pattern and if-convert it. Fixed a regression in the original commit. Need to un-reverse branches after reversing them, or other conversions go awry. define i32 @t2(i32 %a, i32 %b) nounwind { entry: %tmp1434 = icmp eq i32 %a, %b ; <i1> [#uses=1] br i1 %tmp1434, label %bb17, label %bb.outer bb.outer: ; preds = %cond_false, %entry %b_addr.021.0.ph = phi i32 [ %b, %entry ], [ %tmp10, %cond_false ] %a_addr.026.0.ph = phi i32 [ %a, %entry ], [ %a_addr.026.0, %cond_false ] br label %bb bb: ; preds = %cond_true, %bb.outer %indvar = phi i32 [ 0, %bb.outer ], [ %indvar.next, %cond_true ] %tmp. = sub i32 0, %b_addr.021.0.ph %tmp.40 = mul i32 %indvar, %tmp. %a_addr.026.0 = add i32 %tmp.40, %a_addr.026.0.ph %tmp3 = icmp sgt i32 %a_addr.026.0, %b_addr.021.0.ph br i1 %tmp3, label %cond_true, label %cond_false cond_true: ; preds = %bb %tmp7 = sub i32 %a_addr.026.0, %b_addr.021.0.ph %tmp1437 = icmp eq i32 %tmp7, %b_addr.021.0.ph %indvar.next = add i32 %indvar, 1 br i1 %tmp1437, label %bb17, label %bb cond_false: ; preds = %bb %tmp10 = sub i32 %b_addr.021.0.ph, %a_addr.026.0 %tmp14 = icmp eq i32 %a_addr.026.0, %tmp10 br i1 %tmp14, label %bb17, label %bb.outer bb17: ; preds = %cond_false, %cond_true, %entry %a_addr.026.1 = phi i32 [ %a, %entry ], [ %tmp7, %cond_true ], [ %a_addr.026.0, %cond_false ] ret i32 %a_addr.026.1 } Without tail-merging or diamond-tail if conversion: LBB1_1: @ %bb @ =>This Inner Loop Header: Depth=1 cmp r0, r1 ble LBB1_3 @ BB#2: @ %cond_true @ in Loop: Header=BB1_1 Depth=1 subs r0, r0, r1 cmp r1, r0 it ne cmpne r0, r1 bgt LBB1_4 LBB1_3: @ %cond_false @ in Loop: Header=BB1_1 Depth=1 subs r1, r1, r0 cmp r1, r0 bne LBB1_1 LBB1_4: @ %bb17 bx lr With diamond-tail if conversion, but without tail-merging: @ BB#0: @ %entry cmp r0, r1 it eq bxeq lr LBB1_1: @ %bb @ =>This Inner Loop Header: Depth=1 cmp r0, r1 ite le suble r1, r1, r0 subgt r0, r0, r1 cmp r1, r0 bne LBB1_1 @ BB#2: @ %bb17 bx lr llvm-svn: 278287
* LiveIntervalAnalysis: fix a crash in repairOldRegInRangeNicolai Haehnle2016-08-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See the new test case for one that was (non-deterministically) crashing on trunk and deterministically hit the assertion that I added in D23302. Basically, the machine function contains a sequence DS_WRITE_B32 %vreg4, %vreg14:sub0, ... DS_WRITE_B32 %vreg4, %vreg14:sub0, ... %vreg14:sub1<def> = COPY %vreg14:sub0 and SILoadStoreOptimizer::mergeWrite2Pair merges the two DS_WRITE_B32 instructions into one before calling repairIntervalsInRange. Now repairIntervalsInRange wants to repair %vreg14, in particular, and ends up trying to repair %vreg14:sub1 as well, but that only becomes active _after_ the range that is to be repaired, hence the crash due to LR.find(...) == LR.begin() at the start of repairOldRegInRange. I believe that just skipping those subrange is fine, but again, not too familiar with that code. Reviewers: MatzeB, kparzysz, tstellarAMD Subscribers: llvm-commits, MatzeB Differential Revision: https://reviews.llvm.org/D23303 llvm-svn: 278268
* Codegen: Tail Merge: Be less aggressive with special cases.Kyle Butt2016-08-101-4/+13
| | | | | | | | | | | | This change makes it possible for tail-duplication and tail-merging to be disjoint. By being less aggressive when merging during layout, there are no overlapping cases between tail-duplication and tail-merging, provided the thresholds are disjoint. There is a remaining TODO to benchmark the succ_size() test for non-layout tail merging. llvm-svn: 278265
* GlobalISel: avoid inserting redundant COPYs for bitcasts.Tim Northover2016-08-101-2/+5
| | | | | | | If the value produced by the bitcast hasn't been referenced yet, we can simply reuse the input register avoiding an unnecessary COPY instruction. llvm-svn: 278245
* [DAGCombine] Avoid INSERT_SUBVECTOR reinsertions (PR28678)Simon Pilgrim2016-08-101-1/+10
| | | | | | | | | | | If the input vector to INSERT_SUBVECTOR is another INSERT_SUBVECTOR, and this inserted subvector replaces the last insertion, then insert into the common source vector. i.e. INSERT_SUBVECTOR( INSERT_SUBVECTOR( Vec, SubOld, Idx ), SubNew, Idx ) --> INSERT_SUBVECTOR( Vec, SubNew, Idx ) Differential Revision: https://reviews.llvm.org/D23330 llvm-svn: 278211
* GlobalISel: support 'undef' constant.Tim Northover2016-08-091-4/+6
| | | | llvm-svn: 278174
* GlobalISel: first translation support for Constants.Tim Northover2016-08-091-1/+23
| | | | | | | | | For now put them all in the entry block. This should be correct but may give poor runtime performance. Hopefully MachineSinking combined with isReMaterializable can solve those issues, but if not the interface is sound enough to support alternatives. llvm-svn: 278168
* [DAGCombiner] Better support for shifting large value type by constantsSimon Pilgrim2016-08-091-17/+42
| | | | | | | | | | As detailed on D22726, much of the shift combining code assume constant values will fit into a uint64_t value and calls ConstantSDNode::getZExtValue where it probably shouldn't (leading to asserts). Using APInt directly avoids this problem but we encounter other assertions if we attempt to compare/operate on 2 APInt of different bitwidths. This patch adds a helper function to ensure that 2 APInt values are zero extended as required so that they can be safely used together. I've only added an initial example use for this to the '(SHIFT (SHIFT x, c1), c2) --> (SHIFT x, (ADD c1, c2))' combines. Further cases can easily be added as required. Differential Revision: https://reviews.llvm.org/D23007 llvm-svn: 278141
* Revert "[X86] Support the "ms-hotpatch" attribute."Charles Davis2016-08-081-14/+16
| | | | | | | | This reverts commit r278048. Something changed between the last time I built this--it takes awhile on my ridiculously slow and ancient computer--and now that broke this. llvm-svn: 278053
* [X86] Support the "ms-hotpatch" attribute.Charles Davis2016-08-081-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Based on two patches by Michael Mueller. This is a target attribute that causes a function marked with it to be emitted as "hotpatchable". This particular mechanism was originally devised by Microsoft for patching their binaries (which they are constantly updating to stay ahead of crackers, script kiddies, and other ne'er-do-wells on the Internet), but is now commonly abused by Windows programs to hook API functions. This mechanism is target-specific. For x86, a two-byte no-op instruction is emitted at the function's entry point; the entry point must be immediately preceded by 64 (32-bit) or 128 (64-bit) bytes of padding. This padding is where the patch code is written. The two byte no-op is then overwritten with a short jump into this code. The no-op is usually a `movl %edi, %edi` instruction; this is used as a magic value indicating that this is a hotpatchable function. Reviewers: majnemer, sanjoy, rnk Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D19908 llvm-svn: 278048
* [SelectionDAG] Refactor visitInlineAsm a bit. NFCI.Diana Picus2016-08-081-151/+198
| | | | | | This shaves off ~100 lines from visitInlineAsm. llvm-svn: 277987
* [MC] Delete use of *structors_used.Davide Italiano2016-08-081-12/+0
| | | | | | | Jim Grosbach and Kevin Enderby think those are not used anymore. Originally submitted by: Rafael Espindola llvm-svn: 277973
* Revert r277905, it caused PR28894Nico Weber2016-08-071-345/+66
| | | | llvm-svn: 277962
* Move helpers into anonymous namespaces. NFC.Benjamin Kramer2016-08-066-11/+11
| | | | llvm-svn: 277916
* [CodeGen] Fix a -Wdocumentation warningDavid Majnemer2016-08-061-1/+1
| | | | | | | A parameter was documented with the wrong name. No functionality change is intended. llvm-svn: 277915
OpenPOWER on IntegriCloud