summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [ASan] Update uses of IRBuilder::CreateMemCpy to new API (NFC)Daniel Neilson2018-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the AddressSanitizer pass to cease using The old IRBuilder CreateMemCpy single-alignment API in favour of the new API that allows setting source and destination alignments independently. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626, rL324642 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 324653
* Revert "WIP: [DAGCombiner] Assert that debug info is preserved"Vedant Kumar2018-02-081-31/+4
| | | | | | This reverts commit r324648. It was committed accidentally. llvm-svn: 324650
* WIP: [DAGCombiner] Assert that debug info is preservedVedant Kumar2018-02-081-4/+31
| | | | llvm-svn: 324648
* [X86] Remove kortest intrinsics and replace with native IR.Craig Topper2018-02-082-10/+15
| | | | llvm-svn: 324646
* [X86] Support 'V' register operand modifierDavid Woodhouse2018-02-081-1/+10
| | | | | | | | This allows the register name to be printed without the leading '%'. This can be used for emitting calls to the retpoline thunks from inline asm. llvm-svn: 324645
* [MSan] Update uses of IRBuilder::CreateMemCpy to new API (NFC)Daniel Neilson2018-02-081-19/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the MemorySanitizer pass to cease using the old IRBuilder CreateMemCpy single-alignment APIs in favour of the new API that allows setting source and destination alignments independently. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 324642
* [InstCombine] visitSRem - use m_Negative(APInt) helper. NFCI.Simon Pilgrim2018-02-081-1/+1
| | | | llvm-svn: 324636
* [SelectionDAG] Add a helper function for creating a boolean constant based ↵Craig Topper2018-02-082-82/+82
| | | | | | | | | | | | | on the target's boolean content Many in SimplifySetCC and FoldSetCC try to create true or false constants. Some of them query getBooleanContents to figure out whether to use all ones or just 1 for true. But many places do not check and just use 1 without ensuring the VT has an i1 scalar type. Note sure if those places only trigger before type legalization so they only see an i1 type? To cleanup the inconsistency and reduce some duplicated code, this patch adds a getBoolConstant method to SelectionDAG that takes are of querying getBooleanContents and doing the right thing. Differential Revision: https://reviews.llvm.org/D43037 llvm-svn: 324634
* [InstCombine] Add m_Negative pattern matchingSimon Pilgrim2018-02-081-2/+1
| | | | | | Allows us to add non-uniform constant vector support for "X urem C -> X < C ? X : X - C, where C >= signbit." llvm-svn: 324631
* Use ranged for loops in TypeFinder.cpp, NFCVedant Kumar2018-02-081-30/+20
| | | | llvm-svn: 324628
* [LoopIdiom] Be more aggressive when setting alignment in memcpyDaniel Neilson2018-02-081-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the LoopIdiom pass to cease using the old IRBuilder CreateMemCpy single-alignment APIs in favour of the new API that allows setting source and destination alignments independently. This allows us to be slightly more aggressive in setting the alignment of memcpy calls that loop idiom creates. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 324626
* [ARM] Add 'fillValidCPUArchList' to ARM targetsErich Keane2018-02-081-0/+14
| | | | | | | | | This is a support change for a CFE change (https://reviews.llvm.org/D42978) that allows march and -target-cpu to list the valid targets in a note. The changes are limited to the ARM/AArch64, since this is the only target that gets the CPU list from LLVM. llvm-svn: 324623
* [InstCombine] Fix issue with X udiv (POW2_C1 << N) for non-splat constant ↵Simon Pilgrim2018-02-081-4/+6
| | | | | | | | vectors foldUDivShl was assuming that the input was a scalar or a splat constant llvm-svn: 324613
* [ValueTracking] don't crash when assumptions conflict (PR36270)Sanjay Patel2018-02-081-0/+8
| | | | | | | | | | | | | | The last assume in the test says that %B12 is 0. The first assume says that %and1 is less than %B12. Therefore, %and1 is unsigned less than 0...does not compute. That means this line: Known.Zero.setHighBits(RHSKnown.countMinLeadingZeros() + 1); ...tries to set more bits than exist. Differential Revision: https://reviews.llvm.org/D43052 llvm-svn: 324610
* [InstCombine] Fix issue with X udiv 2^C -> X >> C for non-splat constant vectorsSimon Pilgrim2018-02-081-3/+4
| | | | | | foldUDivPow2Cst was assuming that the input was a scalar or a splat constant llvm-svn: 324608
* [ARM] Re-commit r324600 with fixed LLVMBuild.txtOliver Stannard2018-02-082-10/+3
| | | | | | | | | | | | | | | | | | | | | | ARMDisassembler now depends on the banked register tables in ARMUtils, so the LLVMBuild.txt needed updating to reflect this. Original commit mesage: [ARM] Fix disassembly of invalid banked register moves When disassembling banked register move instructions, we don't have an assembly syntax for the unallocated register numbers, so we have to return Fail rather than SoftFail. Previously we were returning SoftFail, then crashing in the InstPrinter as we have no way to represent these encodings in an assembly string. This also switches the decoder to use the table-generated list of banked registers, removing the duplicated list of encodings. Differential revision: https://reviews.llvm.org/D43066 llvm-svn: 324606
* Fix unused variable warning.Simon Pilgrim2018-02-081-1/+1
| | | | llvm-svn: 324605
* Revert r324600 as it breaks a buildbotOliver Stannard2018-02-081-2/+9
| | | | | | | | The broken bot (clang-ppc64le-linux-multistage) is doign a shared-object build, so I guess using lookupBankedRegByEncoding in the disassembler is a layering violation? llvm-svn: 324604
* [InstCombine] Improve mul(x, pow2) -> shl combine for vector constantsSimon Pilgrim2018-02-081-17/+21
| | | | | | Refactor getLogBase2Vector into getLogBase2 to accept all scalars/vectors. Generalize from ConstantDataVector to support all constant vectors. llvm-svn: 324603
* [ARM] Fix disassembly of invalid banked register movesOliver Stannard2018-02-081-9/+2
| | | | | | | | | | | | | | | When disassembling banked register move instructions, we don't have an assembly syntax for the unallocated register numbers, so we have to return Fail rather than SoftFail. Previously we were returning SoftFail, then crashing in the InstPrinter as we have no way to represent these encodings in an assembly string. This also switches the decoder to use the table-generated list of banked registers, removing the duplicated list of encodings. Differential revision: https://reviews.llvm.org/D43066 llvm-svn: 324600
* Add missed PostDominatorTree analysis dependency to GVN hoist pass.Alexander Ivchenko2018-02-081-0/+1
| | | | | | | | | | | | | Summary: GVN hoist pass is using PostDominatorTree analysis, therefore the analysis should be listed in the pass initialization as a dependency. Reviewed By: sebpop Differential Revision: https://reviews.llvm.org/D43007 Author: ashlykov <arkady.shlykov@intel.com> llvm-svn: 324597
* [Loop Predication] Teach LP about reverse loops with uge and sge latch ↵Serguei Katkov2018-02-081-5/+8
| | | | | | | | | | | | | | conditions Add support of uge and sge latch condition to Loop Prediction for reverse loops. Reviewers: apilipenko, mkazantsev, sanjoy, anna Reviewed By: anna Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42837 llvm-svn: 324589
* [X86] Fix compilation of r324580.Clement Courbet2018-02-081-1/+1
| | | | | | @ctopper Can you check that the fix is correct ? llvm-svn: 324586
* Revert accidental changes that snuck in r324584Stefan Maksimovic2018-02-083-10/+1
| | | | llvm-svn: 324585
* [mips] Define certain instructions in microMIPS32r3Stefan Maksimovic2018-02-089-155/+162
| | | | | | | | | | | | | | | | | | | | Instructions affected: mthc1, mfhc1, add.d, sub.d, mul.d, div.d, mov.d, neg.d, cvt.w.d, cvt.d.s, cvt.d.w, cvt.s.d These instructions are now defined for microMIPS32r3 + microMIPS32r6 in MicroMipsInstrFPU.td since they shared their encoding with those already defined in microMIPS32r6InstrInfo.td and have been therefore removed from the latter file. Some instructions present in MicroMipsInstrFPU.td which did not have both AFGR64 and FGR64 variants defined have been altered to do so. Differential revision: https://reviews.llvm.org/D42738 llvm-svn: 324584
* [AArch64] Don't materialize 0 with "fmov h0, .." when FullFP16 is not supportedSjoerd Meijer2018-02-082-2/+3
| | | | | | | | | | | | | | We were generating "fmov h0, wzr" instructions when FullFP16 is not enabled. I've not added any tests, because the problem was visible in: test/CodeGen/AArch64/arm64-zero-cycle-zeroing.ll, which I had to change: I don't think Cyclone has FullFP16 enabled by default, so it shouldn't be using this v8.2a instruction. I've also removed these rdar tags, please shout if there are any objections. Differential Revision: https://reviews.llvm.org/D43020 llvm-svn: 324581
* [X86] Support folding in a k-register OR when creating KORTEST from scalar ↵Craig Topper2018-02-081-1/+9
| | | | | | | | compare of a bitcast from vXi1. This should allow us to remove the kortest intrinsic from IR and use compare+bitcast+or in IR instead. llvm-svn: 324580
* [X86] Allow KORTEST instruction to be used for testing if a mask is all onesCraig Topper2018-02-081-3/+7
| | | | | | | | The KTEST instruction sets the C flag if the result of anding both operands together is all 1s. We can use this to lower (icmp eq/ne (bitcast (vXi1 X), -1) Differential Revision: https://reviews.llvm.org/D42772 llvm-svn: 324577
* [X86] Don't emit KTEST instructions unless only the Z flag is being usedCraig Topper2018-02-082-29/+40
| | | | | | | | | | | | | | | | | | | | | | | Summary: KTEST has weird flag behavior. The Z flag is set for all bits in the AND of the k-registers being 0, and the C flag is set for all bits being 1. All other flags are cleared. We currently emit this instruction in EmitTEST and don't check the condition code. This can lead to strange things like using the S flag after a KTEST for a signed compare. The domain reassignment pass can also transform TEST instructions into KTEST and is not protected against the flag usage either. For now I've disabled this part of the domain reassignment pass. I tried to comment out the checks in the mir test so that we could recover them later, but I couldn't figure out how to get that to work. This patch moves the KTEST handling into LowerSETCC and now creates a ktest+x86setcc. I've chosen this approach because I'd like to add support for the C flag for all ones in a followup patch. To do that requires that I can rewrite the condition code going in the x86setcc to be different than the original SETCC condition code. This fixes PR36182. I'll file a PR to fix domain reassignment once this goes in. Should this be merged to 6.0? Reviewers: spatel, guyblank, RKSimon, zvi Reviewed By: guyblank Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42770 llvm-svn: 324576
* Recommit r324455 "[ThinLTO] - Simplify code in ThinLTOBitcodeWriter."George Rimar2018-02-081-40/+12
| | | | | | | | | | | | | With fix: reimplemented. Original commit message: Recently introduced convertToDeclaration is very similar to code used in filterModule function. Patch reuses it to reduce duplication. Differential revision: https://reviews.llvm.org/D42971 llvm-svn: 324574
* [SimplifyCFG] Re-apply Relax restriction for folding unconditional branchesSerguei Katkov2018-02-081-1/+4
| | | | | | | | | | | | | | | | | | | | | The commit rL308422 introduces a restriction for folding unconditional branches. Specifically if empty block with unconditional branch leads to header of the loop then elimination of this basic block is prohibited. However it seems this condition is redundantly strict. If elimination of this basic block does not introduce more back edges then we can eliminate this block. The patch implements this relax of restriction. The test profile/Linux/counter_promo_nest.c in compiler-rt project is updated to meet this change. Reviewers: efriedma, mcrosier, pacxx, hsung, davidxl Reviewed By: pacxx Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42691 llvm-svn: 324572
* [DAGCombiner] Fix a couple mistakes from r324311 by really passing the ↵Craig Topper2018-02-081-2/+4
| | | | | | | | | | original load to ExtendSetCCUses. We're passing the binary op that uses the load instead of the load. Noticed by inspection. Not sure how to test this because this just prevents the introduction of an extend that will later be truncated and will probably be combined out. llvm-svn: 324568
* [DAGCombiner] Don't create truncate nodes in (aext (zextload x)) -> ↵Craig Topper2018-02-081-15/+5
| | | | | | | | (zextload x) and similar folds. NFCI The truncate is being used to replace other users of of the load, but we checked that the load only has one use so there are no other uses to replace. llvm-svn: 324567
* ARM: Remove dead code. NFCI.Peter Collingbourne2018-02-082-6/+0
| | | | llvm-svn: 324565
* [CodeGen] Print MachineBasicBlock labels using MIR syntax in -debug outputFrancis Visoiu Mistrih2018-02-081-13/+33
| | | | | | | | | | | | | | Instead of: %bb.1: derived from LLVM BB %for.body print: bb.1.for.body: Also use MIR syntax for MBB attributes like "align", "landing-pad", etc. llvm-svn: 324563
* [DAGCombiner] Avoid creating truncate nodes in (zext (and (load)))->(and ↵Craig Topper2018-02-081-22/+25
| | | | | | | | (zextload)) fold until we know for sure we're going to need it. NFCI The truncate is only needed if the load has additional users. It used to get passed to extendSetCCUses so was created early, but that's no longer the case. llvm-svn: 324562
* [DAGCombiner] Rename variable to be slightly better. NFCCraig Topper2018-02-081-21/+21
| | | | | | We were calling a load LN0 but it came from N0.getOperand(0) so its really more like LN00 if we follow the name used in other places. llvm-svn: 324561
* bpf: Improve expanding logic in LowerSELECT_CCYonghong Song2018-02-081-0/+5
| | | | | | | | | | | | | | | LowerSELECT_CC is not generating optimal Select_Ri pattern at the moment. It is not guaranteed to place ConstantNode at RHS which would miss matching Select_Ri. A new testcase added into the existing select_ri.ll, also there is an existing case in cmp.ll which would be improved to use Select_Ri after this patch, it is adjusted accordingly. Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Reviewed-by: Yonghong Song <yhs@fb.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> llvm-svn: 324560
* AMDGPU: Fix incorrect reordering when inline asm defines LDS addressMatt Arsenault2018-02-081-3/+4
| | | | | | | Defs of operands outside of the instruction's explicit defs need to be checked. llvm-svn: 324554
* AMDGPU: Don't crash when trying to fold implicit operandsMatt Arsenault2018-02-081-0/+1
| | | | llvm-svn: 324550
* [NVPTX] When dying due to a bad address space value, print out the value.Justin Lebar2018-02-081-1/+2
| | | | llvm-svn: 324549
* [AMDGPU] Fixed wait count reuseStanislav Mekhanoshin2018-02-081-50/+40
| | | | | | | | | | | | | The code reusing existing wait counts is incorrect since it keeps adding new operands to an old instruction instead of replacing the immediate. It was also effectively switched off by the condition that wait count is not an AMDGPU::S_WAITCNT. Also switched to BuildMI instead of creating instructions directly. Differential Revision: https://reviews.llvm.org/D42997 llvm-svn: 324547
* [x86] Fix nasty bug in the x86 backend that is essentially impossible toChandler Carruth2018-02-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hit from IR but creates a minefield for MI passes. The x86 backend has fairly powerful logic to try and fold loads that feed register operands to instructions into a memory operand on the instruction. This is almost always a good thing, but there are specific relocated loads that are only allowed to appear in specific instructions. Notably, R_X86_64_GOTTPOFF is only allowed in `movq` and `addq`. This patch blocks folding of memory operands using this relocation unless the target is in fact `addq`. The particular relocation indicates why we simply don't hit this under normal circumstances. This relocation is only used for TLS, and it gets used in very specific ways in conjunction with %fs-relative addressing. The result is that loads using this relocation are essentially never eligible for folding into an instruction's memory operands. Unless, of course, you have an MI pass that inserts usage of such a load. I have exactly such an MI pass and was greeted by truly mysterious miscompiles where the linker replaced my instruction with a completely garbage byte sequence. Go team. This is the only such relocation I'm aware of in x86, but there may be others that need to be similarly restricted. Fixes PR36165. Differential Revision: https://reviews.llvm.org/D42732 llvm-svn: 324546
* Verify profile data confirms large loop trip counts.Mircea Trofin2018-02-071-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Loops with inequality comparers, such as: // unsigned bound for (unsigned i = 1; i < bound; ++i) {...} have getSmallConstantMaxTripCount report a large maximum static trip count - in this case, 0xffff fffe. However, profiling info may show that the trip count is much smaller, and thus counter-recommend vectorization. This change: - flips loop-vectorize-with-block-frequency on by default. - validates profiled loop frequency data supports vectorization, when static info appears to not counter-recommend it. Absence of profile data means we rely on static data, just as we've done so far. Reviewers: twoh, mkuper, davidxl, tejohnson, Ayal Reviewed By: davidxl Subscribers: bkramer, llvm-commits Differential Revision: https://reviews.llvm.org/D42946 llvm-svn: 324543
* [X86] Prune some unreachable 'return SDValue()' paths from ↵Craig Topper2018-02-071-31/+26
| | | | | | | | LowerSIGN_EXTEND/LowerZERO_EXTEND/LowerANY_EXTEND. We were doing a lot of whitelisting of what we handle in these routines, but setOperationAction constrains what we can get here. So just add some asserts and prune the unreachable paths. llvm-svn: 324538
* [X86] Remove dead code from EmitTest that looked for an i1 type which should ↵Craig Topper2018-02-071-5/+0
| | | | | | have already been type legalized away. NFC llvm-svn: 324536
* [X86] When doing callee save/restore for k-registers make sure we don't use ↵Craig Topper2018-02-072-5/+25
| | | | | | | | | | | | | | KMOVQ on non-BWI targets If we are saving/restoring k-registers, the default behavior of getMinimalRegisterClass will find the VK64 class with a spill size of 64 bits. This will cause the KMOVQ opcode to be used for save/restore. If we don't have have BWI instructions we need to constrain the class returned to give us VK16 with a 16-bit spill size. We can do this by passing the either v16i1 or v64i1 into getMinimalRegisterClass. Also add asserts to make sure BWI is enabled anytime we use KMOVD/KMOVQ. These are what caught this bug. Fixes PR36256 Differential Revision: https://reviews.llvm.org/D42989 llvm-svn: 324533
* Revert "[DebugInfo] Improvements to representation of enumeration types ↵Momchil Velikov2018-02-078-88/+26
| | | | | | | | (PR36168)" Revert commit r324489, it broke LLDB tests. llvm-svn: 324511
* Revert "AMDGPU: Add 32-bit constant address space"Rafael Espindola2018-02-0712-86/+19
| | | | | | | | This reverts commit r324487. It broke clang tests. llvm-svn: 324494
* [SelectionDAG] More Aggressibly prune nodes in AddChains. NFCI.Nirav Dave2018-02-071-1/+3
| | | | | | | | Travel all chains paths to first non-tokenfactor node can be exponential work. Add simple redundency check to avoid this. Fixes PR36264. llvm-svn: 324491
OpenPOWER on IntegriCloud