summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [LoopInterchange] Use getExitBlock()/getExitingBlock instead of manual impl.Florian Hahn2018-04-251-33/+27
| | | | | | | | | | | | | | | This also means we have to check if the latch is the exiting block now, as `transform` expects the latches to be the exiting blocks too. https://bugs.llvm.org/show_bug.cgi?id=36586 Reviewers: efriedma, davide, karthikthecool Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D45279 llvm-svn: 330806
* [AArch64][SVE] Asm: Add AsmOperand classes for SVE gather/scatter addressing ↵Sander de Smalen2018-04-254-8/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | modes. This patch adds parsing support for 'vector + shift/extend' and corresponding asm operand classes, needed for implementing SVE's gather/scatter addressing modes. The added combinations of vector (ZPR) and Shift/Extend are: Unscaled: ZPR64ExtLSL8: signed 64-bit offsets (z0.d) ZPR32ExtUXTW8: unsigned 32-bit offsets (z0.s, uxtw) ZPR32ExtSXTW8: signed 32-bit offsets (z0.s, sxtw) Unpacked and unscaled: ZPR64ExtUXTW8: unsigned 32-bit offsets (z0.d, uxtw) ZPR64ExtSXTW8: signed 32-bit offsets (z0.d, sxtw) Unpacked and scaled: ZPR64ExtUXTW<scale>: unsigned 32-bit offsets (z0.d, uxtw #<shift>) ZPR64ExtSXTW<scale>: signed 32-bit offsets (z0.d, sxtw #<shift>) Scaled: ZPR32ExtUXTW<scale>: unsigned 32-bit offsets (z0.s, uxtw #<shift>) ZPR32ExtSXTW<scale>: signed 32-bit offsets (z0.s, sxtw #<shift>) ZPR64ExtLSL<scale>: unsigned 64-bit offsets (z0.d, lsl #<shift>) ZPR64ExtLSL<scale>: signed 64-bit offsets (z0.d, lsl #<shift>) Patch [1/3] in series to add support for SVE's gather load instructions that use scalar+vector addressing modes: - Patch [1/3]: https://reviews.llvm.org/D45951 - Patch [2/3]: https://reviews.llvm.org/D46023 - Patch [3/3]: https://reviews.llvm.org/D45958 Reviewers: fhahn, rengolin, samparker, SjoerdMeijer, t.p.northover, echristo, evandro, javed.absar Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D45951 llvm-svn: 330805
* [DebugInfo] Invalidate debug info in ReassociatePass::RewriteExprTreeBjorn Pettersson2018-04-251-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When Reassociate is rewriting an expression tree it may reuse old binary expression nodes, for new expressions. Whenever an expression node is reused, but with a non-trivial change in the result, we need to invalidate any debug info that is associated with the node. If for example rewriting x = mul a, b y = mul c, x into x = mul c, b y = mul a, x we still get the same result for 'y', but 'x' is a new expression. All debug info referring to 'x' must be invalidated (marked as optimized out) since we no longer calculate the expected value. As a side-effect this patch avoid (at least some) problems where reassociate could end up creating IR with debug-use before def. Earlier the dbg.value nodes where left untouched in the IR, while the reused binary nodes where sinked to just before the root node of the rewritten expression tree. See PR27273 for more info about such problems. Reviewers: dblaikie, aprantl, dexonsmith Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D45975 llvm-svn: 330804
* Merging r46043:David Bolvansky2018-04-251-3/+3
| | | | | | ------------------------------------------------------------------------ llvm-svn: 330799
* [DivRemPairs] Fix non-determinism in use list order.Geoff Berry2018-04-251-3/+8
| | | | | | | | | | | | | | | | | Summary: Use a MapVector instead of a DenseMap for RemMap since it is iteratated over and the order of iteration can effect the order that new instructions are created. This can in turn effect the use list order of div/rem input values if multiple new instructions are created that share any input values. Reviewers: spatel Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D45858 llvm-svn: 330792
* [PM/LoopUnswitch] Begin teaching SimpleLoopUnswitch to use the newChandler Carruth2018-04-251-70/+78
| | | | | | | | | | | | | | | | | | | | | | | update API for dominators rather than doing manual, hacky updates. This is just the first step, but in some ways the most important as it moves the non-trivial unswitching to update the domtree rather than fully recalculating it each time. Subsequent patches should remove the custom update logic used by the trivial unswitch and replace it with uses of the update API. This also fixes a number of bugs I was seeing when testing non-trivial unswitch due to it querying the quasi-correct dominator tree. Now the tree is 100% correct and safe to query. That said, there are still more bugs I can see with non-trivial unswitch just running over the test suite, so more bugfix patches are needed as well. Thanks to both Sanjoy and Fedor for reviews and testing! Differential Revision: https://reviews.llvm.org/D45943 llvm-svn: 330787
* [MachineOutliner] Check for explicit uses of LR/W30 in MI operandsJessica Paquette2018-04-241-0/+5
| | | | | | | | | | Before, the outliner would grab ADRPs that used LR/W30. This patch fixes that by checking for explicit uses of those registers before the special-casing for ADRPs. This also adds a test that ensures that those sorts of ADRPs won't be outlined. llvm-svn: 330783
* [DAGCombiner][X86] When promoting loads don't use ZEXTLOAD even its legalCraig Topper2018-04-241-8/+4
| | | | | | | | | | | | We were previously prefering ZEXTLOAD over EXTLOAD if it is legal. This triggers during X86's promotion of i16->i32. Not sure about other targets. Using ZEXTLOAD can prevent folding it to SEXTLOAD later if we were to promote a sign extended operand like we would need for SRA. However, X86 doesn't currently promote i16 SRA. I was looking into doing that which is how I found this issue. This is also blocking our ability to fold 4 byte aligned EXTLOADs with "loadi32". This is what caused most of the test changes here. Differential Revision: https://reviews.llvm.org/D45585#inline-402825 llvm-svn: 330781
* [X86] Account for partial stack slot spills (PR30821)Warren Ristow2018-04-243-81/+134
| | | | | | | | | | | | | | | | | | | | | | | Previously, _any_ store or load instruction was considered to be operating on a spill if it had a frameindex as an operand, and thus was fair game for optimisations such as "StackSlotColoring". This usually works, except on architectures where spills can be partially restored, for example on X86 where a spilt vector can have a single component loaded (zeroing the rest of the target register). This can be mis-interpreted and the zero extension unsoundly eliminated, see pr30821. To avoid this, this commit optionally provides the caller to isLoadFromStackSlot and isStoreToStackSlot with the number of bytes spilt/loaded by the given instruction. Optimisations can then determine that a full spill followed by a partial load (or vice versa), for example, cannot necessarily be commuted. Patch by Jeremy Morse! Differential Revision: https://reviews.llvm.org/D44782 llvm-svn: 330778
* AMDGPU: Remove deprecated llvm.AMDGPU.kilp intrinsicTom Stellard2018-04-243-11/+0
| | | | | | | | | | | | | | Summary: This is no longer used by mesa since its 18.0.0 release. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arsenm, kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D45988 llvm-svn: 330775
* AMDGPU/GlobalISel: Fall-back to SelectionDAG for non-void functionsTom Stellard2018-04-241-0/+4
| | | | | | | | | | | | Reviewers: arsenm, nhaehnle Reviewed By: nhaehnle Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D45843 llvm-svn: 330774
* [CaptureTracking] Fixup const correctness of DomTree arg (NFC)Daniel Neilson2018-04-241-3/+3
| | | | | | | | | Summary: The PointerMayBeCapturedBefore function's DomTree arg should be const instead of non-const. There are no non-const uses of it in the function. llvm-svn: 330769
* AMDGPU/GlobalISel: Add support for amdgpu_ps calling conventionTom Stellard2018-04-241-14/+49
| | | | | | | | | | | | Reviewers: arsenm Reviewed By: arsenm Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D45837 llvm-svn: 330767
* [wasm] Fix uninitialized memory introduced in r330749.Chandler Carruth2018-04-241-1/+1
| | | | | | | Found with MSan. This was causing all the WASM MC tests to fail about 10% of the time. llvm-svn: 330764
* [X86][SKX] Setup WriteFMul and remove unnecessary InstRW scheduler overrides.Simon Pilgrim2018-04-241-27/+1
| | | | llvm-svn: 330760
* [X86] Split off PHMINPOSUW to their own schedule classSimon Pilgrim2018-04-2411-12/+14
| | | | | | This also fixes Jaguar's schedule which was treating it as the WriteVecIMul default. llvm-svn: 330756
* [AMDGPU] Truncate packed inline constantStanislav Mekhanoshin2018-04-242-1/+8
| | | | | | | | | | | | | | | | If a packed inline constant is sign extended it must be truncated after the shift. I.e. a constant (0xH0000, 0xHBC00), will be represented as 0xFFFFFFFFBC000000 in the IR because the immediate is sign extended to 64 bit. After the value shifted right by 16 to use it in a low part with op_sel_hi it becomes 0xFFFFFFFFBC00 and does not qualify as inline constant any longer. Fixed the error and added verification code. Without the fix and with the verification bug is causing pk_max_f16_literal.ll to fail. Differential Revision: https://reviews.llvm.org/D45987 llvm-svn: 330752
* [XOP] v4i32 IFMA 'VPMACS' instructions should use the WritePMULLD schedule classSimon Pilgrim2018-04-241-15/+28
| | | | llvm-svn: 330751
* [WebAssembly] Use section index in relocation section headerSam Clegg2018-04-242-78/+37
| | | | | | | | | | | Rather than referring to sections my their code, use the absolute index of the target section within the module. See https://github.com/WebAssembly/tool-conventions/issues/52 Differential Revision: https://reviews.llvm.org/D45980 llvm-svn: 330749
* [AVX512] VPERMQ/VPERMPD/VPERMIL single op shuffles are not variable shufflesSimon Pilgrim2018-04-241-4/+5
| | | | | | These variants all take an immediate shuffle mask value and should be scheduled as such. llvm-svn: 330747
* Let TableGen write output only if it changed, instead of doing so in cmake.Nico Weber2018-04-241-5/+16
| | | | | | | | | | | Removes one subprocess and one temp file from the build for each tablegen invocation. No intended behavior change. https://reviews.llvm.org/D45899 llvm-svn: 330742
* Reland "[mips] Guard traps for microMIPS correctly"Simon Dardis2018-04-242-28/+39
| | | | | | | | | | | | | | This is part of fixing the instruction predicates for MIPS. Reviewers: atanasyan, abeserminji Differential Revision: https://reviews.llvm.org/D44212 This patch relands r327409, hopefully without the problematic part of the tests that cause FileCheck to assert on the windows expensive checks bot. llvm-svn: 330741
* [LV][VPlan] Detect outer loops for explicit vectorization.Diego Caballero2018-04-242-29/+394
| | | | | | | | | | | | | | | | | Patch #2 from VPlan Outer Loop Vectorization Patch Series #1 (RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119523.html). This patch introduces the basic infrastructure to detect, legality check and process outer loops annotated with hints for explicit vectorization. All these changes are protected under the feature flag -enable-vplan-native-path. This should make this patch NFC for the existing inner loop vectorizer. Reviewers: hfinkel, mkuper, rengolin, fhahn, aemerson, mssimpso. Differential Revision: https://reviews.llvm.org/D42447 llvm-svn: 330739
* [LoopInterchange] Make isProfitableForVectorization slightly more conservative.Florian Hahn2018-04-241-1/+2
| | | | | | | | | | | | | | | | After D43236, we started interchanging loops with empty dependence matrices. In isProfitableForVectorization, we try to determine if interchanging makes the loop dependences more friendly to the vectorizer. If there are no dependences, we should not interchange, based on that heuristic. Reviewers: efriedma, mcrosier, karthikthecool, blitz.opensource Reviewed By: mcrosier Differential Revision: https://reviews.llvm.org/D45208 llvm-svn: 330738
* [X86][F16C] Add WriteCvtF2FSt scheduling classSimon Pilgrim2018-04-2412-48/+46
| | | | | | Fixes the classification of VCVTPS2PHmr/VCVTPS2PHYmr which were tagged as WriteCvtF2FLd_WriteRMW (PR36887) llvm-svn: 330737
* [X86][BtVer2] Fix VCVTPS2PHmr/VCVTPS2PHYmr latenciesSimon Pilgrim2018-04-241-2/+2
| | | | | | These are stores, not loads, so don't need to account for load latency. llvm-svn: 330735
* [mips] Show an error if register number is out of rangeSimon Atanasyan2018-04-241-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code does not check that a register number is in the 0-31 range. Sometimes the parser checks that later for some kinds of instructions, but that leads to unclear / incorrect error messages like that: % cat test.s .text lb $4, 8($32) % llvm-mc test.s -triple=mips64-unknown-linux test.s:2:10: error: expected memory with 16-bit signed offset lb $4, 8($32) ^ Sometimes the parser just crashes: % cat test.s .text lw $4, 8($32) % llvm-mc test.s -triple=mips64-unknown-linux This patch resolves the problem by checking that register number after '$' sign is in the 0-31 range. If the number is out of the range the parser shows the `invalid register number` error, but treats invalid register number as a normal one to continue parsing and catch other possible errors. Differential Revision: https://reviews.llvm.org/D45919 llvm-svn: 330732
* [AMDGPU][Waitcnt] NFC. Cleanup some code/naming consistency:Mark Searles2018-04-241-38/+38
| | | | | | - s/SWaitcnt/Waitcnt s/WaitCnt/Waitcnt llvm-svn: 330730
* Fix some layering in AggressiveInstCombine (avoiding inclusion of Scalar.h)David Blaikie2018-04-243-5/+6
| | | | llvm-svn: 330726
* [LoadStoreVectorize] Ignore interleaved invariant loads.Benjamin Kramer2018-04-241-5/+13
| | | | | | | | | The memory location an invariant load is using can never be clobbered by any store, so it's safe to move the load ahead of the store. Differential Revision: https://reviews.llvm.org/D46011 llvm-svn: 330725
* [X86] Remove unnecessary FMA reg-mem InstRW scheduler overrides.Simon Pilgrim2018-04-244-15/+1
| | | | llvm-svn: 330720
* [SystemZ] Use preferred 16-byte function alignmentUlrich Weigand2018-04-241-0/+2
| | | | | | | | While not necessary for correctness, it is preferable for performance reasons on all architectures we currently support to align functions to 16-byte boundaries by default. llvm-svn: 330718
* [X86] Add vector element insertion/extraction scheduler classesSimon Pilgrim2018-04-2413-244/+184
| | | | | | | | | | | | Split off pinsr/pextr and extractps instructions. (Mostly) fixes PR36887. Note: It might be worth adding a WriteFInsertLd class as well in the future. Differential Revision: https://reviews.llvm.org/D45929 llvm-svn: 330714
* [X86] Replace action Promote with Expand for operation ISD::SINT_TO_FPAlexander Ivchenko2018-04-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: If attribute "use-soft-float"="true" is set then X86ISelLowering.cpp sets 'Promote' action for ISD::SINT_TO_FP operation on type i32. But 'Promote' action is not proper in this case since lib function __floatsidf is available for casting from signed int to float type. Thus Expand action is more suitable here. The Expand action should be set for ISD::UINT_TO_FP for soft float as well. If function attribute "use-soft-float"="true" is set then infinite looping can happen in DAG combining, function visitSINT_TO_FP() replaces SINT_TO_FP node with UINT_TO_FP node and function combineUIntToFP() replace vice versa in cycle. The fix prevents it. Patch by vrybalov Differential Revision: https://reviews.llvm.org/D45572 llvm-svn: 330711
* [CodeGen] Print user-friendly debug locations as MI commentsFrancis Visoiu Mistrih2018-04-241-1/+14
| | | | | | | | | | | | If available, print the file, line and column of the DebugLoc attached to the MachineInstr: MOV16mr $rbp, 1, $noreg, -112, $noreg, killed renamable $ax, debug-location !56 :: (store 2 into %ir.._value12); stepping.swift:10:17 renamable $edx = MOVZX32rm16 $rbp, 1, $noreg, -112, $noreg, debug-location !62 :: (dereferenceable load 2 from %ir.._value13); stepping.swift:10:17 Differential Revision: https://reviews.llvm.org/D45992 llvm-svn: 330709
* [PM/LoopUnswitch] Fix a bug in the loop block set formation of the newChandler Carruth2018-04-241-4/+10
| | | | | | | | | | | | | | | | | | loop unswitch. This code incorrectly added the header to the loop block set early. As a consequence we would incorrectly conclude that a nested loop body had already been visited when the header of the outer loop was the preheader of the nested loop. In retrospect, adding the header eagerly doesn't really make sense. It seems nicer to let the cycle be formed naturally. This will catch crazy bugs in the CFG reconstruction where we can't correctly form the cycle earlier rather than later, and makes the rest of the logic just fall out. I've also added various asserts that make these issues *much* easier to debug. llvm-svn: 330707
* Correct dwarf unwind information in function epiloguePetar Jovanovic2018-04-248-33/+446
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
* [mips] Correct the patterns for bswapSimon Dardis2018-04-243-4/+7
| | | | | | | | | | | | | | Guard the MIPS64 variant correctly for i64, mark the MIPS32 version as not in microMIPS and provide the microMIPS version. Additionally, remove a related stale XFAIL'd test as bswap has its own test case providing coverage. Reviewers: smaksimovic, abeserminji, atanasyan Differential Revision: https://reviews.llvm.org/D45816 llvm-svn: 330705
* [CodeGen] Do not allow opt-bisect-limit to skip ScalarizeMaskedMemIntrin.Andrei Elovikov2018-04-241-3/+0
| | | | | | | | | | | | | | | | | Summary: The pass is supposed to scalarize such intrinsics if the target does not support them natively, so if the scalarization does not happen instruction selection crashes due to inability to lower these intrinsics. Reviewers: andrew.w.kaylor, craig.topper Reviewed By: andrew.w.kaylor Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45947 llvm-svn: 330700
* [NFC] Remove recently added SE verification because it may be false-positiveMax Kazantsev2018-04-242-12/+0
| | | | llvm-svn: 330699
* [AArch64][SVE] Asm: Support for contiguous, first-faulting LDFF1 ↵Sander de Smalen2018-04-242-1/+33
| | | | | | | | | | | | | | (scalar+scalar) load instructions. Reviewers: fhahn, rengolin, samparker, SjoerdMeijer, t.p.northover, echristo, evandro, javed.absar Reviewed By: rengolin Subscribers: tschuett, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D45946 llvm-svn: 330697
* [LVI] Fix typo. NFCXin Tong2018-04-241-1/+1
| | | | llvm-svn: 330688
* [NFC] Use forgetTopmostLoop instead of logic duplicationMax Kazantsev2018-04-241-6/+2
| | | | llvm-svn: 330683
* [X86] Add a BSWAP16 instruction using the 32-bit encoding plus a 0x66 prefix.Craig Topper2018-04-241-2/+6
| | | | | | This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register. llvm-svn: 330682
* [PM/LoopUnswitch] Remove another over-aggressive assert.Chandler Carruth2018-04-241-4/+1
| | | | | | | | | | This code path can very clearly be called in a context where we have baselined all the cloned blocks to a particular loop and are trying to handle nested subloops. There is no harm in this, so just relax the assert. I've added a test case that will make sure we actually exercise this code path. llvm-svn: 330680
* Remove unused function HexagonEarlyIfConversion::replacePhiEdges. NFC.Eric Christopher2018-04-241-15/+0
| | | | llvm-svn: 330678
* [NFC] Add clarification commentMax Kazantsev2018-04-241-2/+4
| | | | llvm-svn: 330677
* Reflow formatting after previous NFC commit.Eric Christopher2018-04-241-6/+6
| | | | llvm-svn: 330676
* Change if-conditionals to else-if as they should all be mutually exclusive.Eric Christopher2018-04-241-3/+3
| | | | | | No functional change intended. llvm-svn: 330675
* InstCombine: Fix layering by not including Scalar.h in InstCombineDavid Blaikie2018-04-243-5/+7
| | | | | | | | (notionally Scalar.h is part of libLLVMScalarOpts, so it shouldn't be included by InstCombine which doesn't/shouldn't need to depend on ScalarOpts) llvm-svn: 330669
OpenPOWER on IntegriCloud