summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [GISel]: Add missing opcodes for overflow intrinsicsAditya Nandakumar2018-08-281-13/+7
| | | | | | | | | | | | | | | | https://reviews.llvm.org/D51197 Currently, IRTranslator (and GISel) seems to be arbitrarily picking which overflow intrinsics get mapped into opcodes which either have a carry as an input or not. For intrinsics such as Intrinsic::uadd_with_overflow, translate it to an opcode (G_UADDO) which doesn't have any carry inputs (similar to LLVM IR). This patch adds 4 missing opcodes for completeness - G_UADDO, G_USUBO, G_SSUBE and G_SADDE. llvm-svn: 340865
* [WebAssembly][NFC] Document stackifier tablegen backendThomas Lively2018-08-281-2/+7
| | | | | | | | | | | | | | Summary: Add comments to help readers avoid having to read tablegen backends to understand the code. Also remove unecessary breaks from the output. Reviewers: dschuff, aheejin Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51371 llvm-svn: 340864
* AMDGPU: Force shrinking of add/sub even if the carry is usedMatt Arsenault2018-08-281-5/+8
| | | | | | | | | The original motivating example uses a 64-bit add, so the carry is used. Insert a copy from VCC. This may allow shrinking of the used carry instruction. At worst, we are replacing a mov to materialize the constant with a copy of vcc. llvm-svn: 340862
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-6/+23
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* AMDGPU: Shrink insts to fold immediatesMatt Arsenault2018-08-284-54/+138
| | | | | | | | | This needs to be done in the SSA fold operands pass to be effective, so there is a bit of overlap with SIShrinkInstructions but I don't think this is practically avoidable. llvm-svn: 340859
* [WebAssembly] v128.notThomas Lively2018-08-281-0/+17
| | | | | | Implementation and tests. llvm-svn: 340857
* AMDGPU: Move canShrink into TIIMatt Arsenault2018-08-283-56/+57
| | | | llvm-svn: 340855
* [DAGCombine] Rework MERGE_VALUES to inline in single pass. NFCI.Nirav Dave2018-08-281-1/+4
| | | | | | | Avoid hyperlinear cost of inlining MERGE_VALUE node by constructing temporary vector and doing a single replacement. llvm-svn: 340853
* [DAG] Avoid recomputing Divergence checks. NFCI.Nirav Dave2018-08-281-6/+10
| | | | | | | When making multiple updates to the same SDNode, recompute node divergence only once after all changes have been made. llvm-svn: 340852
* [DAG] Fix updateDivergence calculationNirav Dave2018-08-281-1/+1
| | | | | | | Check correct SDNode when deciding if we should update the divergence property. llvm-svn: 340851
* AMDGPU: Remove nan tests in class if src is nnanMatt Arsenault2018-08-281-0/+7
| | | | llvm-svn: 340850
* [WebAssembly] Use getCalleeOpNo utility function (NFC)Heejin Ahn2018-08-281-14/+2
| | | | | | | | | | Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51366 llvm-svn: 340848
* [X86] Mark the FUCOMI instructions as requiring CMOV to be enabled. NFCICraig Topper2018-08-281-0/+3
| | | | | | | | These instructions were added on the PentiumPro along with CMOV. This was already comprehended by the lowering process which should emit an alternate sequence using FCOM and FNSTW. This just makes it an explicit error if that doesn't work for some reason. llvm-svn: 340844
* [debuginfo] generate debug info with asm+.fileBrian Cain2018-08-281-8/+8
| | | | | | | | | | | | | | | Summary: For assembly input files, generate debug info even when the .file directive is present, provided it does not include a file-number argument. Fixes PR38695. Reviewers: probinson, sidneym Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D51315 llvm-svn: 340839
* [Inliner] Attribute callsites with inline remarksDavid Bolvansky2018-08-281-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites. An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//. For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons: remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6) remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites: define void @test1() { call void @bar(i1 true) #0 call void @bar(i1 false) #2 ret void } attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" } .. attributes #2 = { "inline-remark"="(cost=never): recursive" } Patch by: yrouban (Yevgeny Rouban) Reviewers: xbolva00, tejohnson, apilipenko Reviewed By: xbolva00, tejohnson Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50435 llvm-svn: 340834
* [AMDGPU] Add support for a16 modifiear for gfx9Ryan Taylor2018-08-289-45/+86
| | | | | | | | | | | | | Summary: Adding support for a16 for gfx9. A16 bit replaces r128 bit for gfx9. Change-Id: Ie8b881e4e6d2f023fb5e0150420893513e5f4841 Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50575 llvm-svn: 340831
* [CloneFunction] Constant fold terminators before checking single predecessorMikael Holmen2018-08-281-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR31105. There is code trying to delete dead code that does so by e.g. checking if the single predecessor of a block is the block itself. That check fails on a block like this bb: br i1 undef, label %bb, label %bb since that has two (identical) predecessors. However, after the check for dead blocks there is a call to ConstantFoldTerminator on the basic block, and that call simplifies the block to bb: br label %bb Therefore we now do the call to ConstantFoldTerminator before the check if the block is dead, so it can realize that it really is. The original behavior lead to the block not being removed, but it was simplified as above, and then we did a call to Dest->replaceAllUsesWith(&*I); with old and new being equal, and an assertion triggered. Reviewers: chandlerc, fhahn Reviewed By: fhahn Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D51280 llvm-svn: 340820
* [GVNHoist] Prune out useless CHI insertionsAlexandros Lamprineas2018-08-281-2/+5
| | | | | | | | | | Fix for the out-of-memory error when compiling SemaChecking.cpp with GVNHoist and ubsan enabled. I've used a cache for inserted CHIs to avoid excessive memory usage. Differential Revision: https://reviews.llvm.org/D50323 llvm-svn: 340818
* [X86][SSE] Improve variable scalar shift of vXi8 vectors (PR34694)Simon Pilgrim2018-08-281-13/+58
| | | | | | | | This patch creates the shift mask and actual shift using the vXi16 vector shift ops. Differential Revision: https://reviews.llvm.org/D51263 llvm-svn: 340813
* [X86][SSE] Avoid vector extraction/insertion for non-constant uniform shiftsSimon Pilgrim2018-08-281-6/+19
| | | | | | As discussed on D51263, we're better off using byte shifts to clear the upper bits on pre-SSE41 hardware. llvm-svn: 340810
* [NFC] A loop can never contain Ret instructionMax Kazantsev2018-08-281-1/+1
| | | | llvm-svn: 340808
* Fix in getAllocationDataForFunctionDavid Chisnall2018-08-281-1/+1
| | | | | | | | | | | | | | | | Summary: Correct to use set like behaviour of AllocType. Should check for subset, not precise value. Reviewers: theraven Reviewed By: theraven Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50959 llvm-svn: 340807
* [X86] Fix some comments to refer to KORTEST not KTEST. NFCCraig Topper2018-08-281-6/+6
| | | | | | KTEST is a different instruction. All of this code uses KORTEST. llvm-svn: 340799
* [DAGCombiner][AMDGPU][Mips] Fold bitcast with volatile loads if the ↵Craig Topper2018-08-281-3/+12
| | | | | | | | | | | | | | | | | | | resulting load is legal for the target. Summary: I'm not sure if this patch is correct or if it needs more qualifying somehow. Bitcast shouldn't change the size of the load so it should be ok? We already do something similar for stores. We'll change the type of a volatile store if the resulting store is Legal or Custom. I'm not sure we should be allowing Custom there... I was playing around with converting X86 atomic loads/stores(except seq_cst) into regular volatile loads and stores during lowering. This would allow some special RMW isel patterns in X86InstrCompiler.td to be removed. But there's some floating point patterns in there that didn't work because we don't fold (f64 (bitconvert (i64 volatile load))) or (f32 (bitconvert (i32 volatile load))). Reviewers: efriedma, atanasyan, arsenm Reviewed By: efriedma Subscribers: jvesely, arsenm, sdardis, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, arichardson, jrtc27, atanasyan, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50491 llvm-svn: 340797
* [InstCombine] Extend (add (sext x), cst) --> (sext (add x, cst')) and (add ↵Craig Topper2018-08-281-2/+4
| | | | | | | | (zext x), cst) --> (zext (add x, cst')) to work for vectors Differential Revision: https://reviews.llvm.org/D51236 llvm-svn: 340796
* [PPC] Remove Darwin support from POWER backend.Kit Barton2018-08-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch issues an error message if Darwin ABI is attempted with the PPC backend. It also cleans up existing test cases, either converting the test to use an alternative triple or removing the test if the coverage is no longer needed. Updated Tests ------------- The majority of test cases were updated to use a different triple that does not include the Darwin ABI. Many tests were also updated to use FileCheck, in place of grep. Deleted Tests ------------- llvm/test/tools/dsymutil/PowerPC/sibling.test was originally added to test specific functionality of dsymutil using an object file created with an old version of llvm-gcc for a Powerbook G4. After a discussion with @JDevlieghere he suggested removing the test. llvm/test/CodeGen/PowerPC/combine_loads_from_build_pair.ll was converted from a PPC test to a SystemZ test, as the behavior is also reproducible there. All other tests that were deleted were specific to the darwin/ppc ABI and no longer necessary. Phabricator Review: https://reviews.llvm.org/D50988 llvm-svn: 340795
* Revert "[CodeGenPrepare] Scan past debug intrinsics to find select ↵David Blaikie2018-08-281-4/+3
| | | | | | | | | | | | | | | candidates (NFC)" This causes crashes due to the interleaved dbg.value intrinsics being left at the end of basic blocks, causing the actual terminators (br, etc) to be not where they should be (not at the end of the block), leading to later crashes. Further discussion on the original commit thread. This reverts commit r340368. llvm-svn: 340794
* [MemorySSA] Add NDEBUG checks to verifiers; NFCGeorge Burgess IV2018-08-281-0/+4
| | | | | | | | verify*() methods are intended to have no side-effects (unless we detect broken MSSA, in which case they assert()), and all of the other verify methods are wrapped by `#ifndef NDEBUG`. llvm-svn: 340793
* [InstCombine] fix formatting; NFCSanjay Patel2018-08-271-1/+2
| | | | llvm-svn: 340790
* [InstCombine] allow shuffle+binop canonicalization with widening shufflesSanjay Patel2018-08-271-4/+14
| | | | | | | | This lines up with the behavior of an existing transform where if both operands of the binop are shuffled, we allow moving the binop before the shuffle regardless of whether the shuffle changes the size of the vector. llvm-svn: 340787
* [PATCH] [InstCombine] Fix issue in the simplification of pow() with nested ↵Evandro Menezes2018-08-271-6/+22
| | | | | | | | | | | exp{,2}() Fix the issue of duplicating the call to `exp{,2}()` when it's nested in `pow()`, as exposed by rL340462. Differential revision: https://reviews.llvm.org/D51194 llvm-svn: 340784
* s/std::set/DenseSet/; NFCGeorge Burgess IV2018-08-271-1/+1
| | | | | | | We only use this set for `insert` and `count`, so a hashing container seems better here. llvm-svn: 340783
* [Pipeliner] Fix incorrect phi values in the epilog and kernelBrendon Cahoon2018-08-271-29/+32
| | | | | | | | | | | | | | | | | | | The code that generates the loop definition operand for phis in the epilog and kernel is incorrect in some cases. In the kernel, when a phi refers to another phi, the code that updates PhiOp2 needs to include the stage difference between the two phis. In the epilog, the check for using the loop definition instead of the phi definition uses the StageDiffAdj value (the difference between the phi stage and the loop definition stage), but the adjustment is not needed to determine if the current stage contains an iteration with the loop definition. Differential Revision: https://reviews.llvm.org/D51167 llvm-svn: 340782
* [WebAssembly] TableGen backend for stackifying instructionsThomas Lively2018-08-272-356/+6
| | | | | | | | | | | | | | | | | Summary: The new stackification backend generates the giant switch statement used to translate instructions to their stackified forms. I did this because it was more interesting than adding all the different vector versions of the various SIMD instructions to the switch statment manually. Reviewers: aardappel, aheejin, dschuff Subscribers: mgorny, sbc100, jgravelle-google, sunfish, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D51318 llvm-svn: 340781
* Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of ↵Roman Tereshin2018-08-271-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SCEVs" This reverts r319889. Unfortunately, wrapping flags are not a part of SCEV's identity (they do not participate in computing a hash value or in equality comparisons) and in fact they could be assigned after the fact w/o rebuilding a SCEV. Grep for const_cast's to see quite a few of examples, apparently all for AddRec's at the moment. So, if 2 expressions get built in 2 slightly different ways: one with flags set in the beginning, the other with the flags attached later on, we may end up with 2 expressions which are exactly the same but have their operands swapped in one of the commutative N-ary expressions, and at least one of them will have "sorted by complexity" invariant broken. 2 identical SCEV's won't compare equal by pointer comparison as they are supposed to. A real-world reproducer is added as a regression test: the issue described causes 2 identical SCEV expressions to have different order of operands and therefore compare not equal, which in its turn prevents LoadStoreVectorizer from vectorizing a pair of consecutive loads. On a larger example (the source of the test attached, which is a bugpoint) I have seen even weirder behavior: adding a constant to an existing SCEV changes the order of the existing terms, for instance, getAddExpr(1, ((A * B) + (C * D))) returns (1 + (C * D) + (A * B)). Differential Revision: https://reviews.llvm.org/D40645 llvm-svn: 340777
* DAG: Check transformed type for forming fminnum/fmaxnum from vselectMatt Arsenault2018-08-271-2/+3
| | | | | | Follow up to r340655 to fix vector types which are split. llvm-svn: 340766
* MachineVerifier: Fix assert on implicit virtreg useMatt Arsenault2018-08-271-2/+4
| | | | | | | | | If the liveness of a physical register was invalid, this was attempting to iterate the subregisters of all register uses of the instruction, which would assert when it encountered an implicit virtual register operand. llvm-svn: 340763
* [PowerPC][MC] Support expressions in getMemRIX16Encoding.Sean Fertile2018-08-271-3/+9
| | | | | | | | | | Loosens an assert in getMemRIX16Encoding that restricts DQ-form instructions to using an immediate, so that we can assemble instructions like lxv/stxv where the offset is an expression. Differential Revision: https://reviews.llvm.org/D51122 llvm-svn: 340761
* [NVPTX] Implement isLegalToVectorizeLoadChainBenjamin Kramer2018-08-271-0/+13
| | | | | | | | This lets LSV nicely split up underaligned chains. Differential Revision: https://reviews.llvm.org/D51306 llvm-svn: 340760
* [X86] When lowering v32i8 MULHS/MULHU, shuffle after the PACKUS rather than ↵Craig Topper2018-08-271-10/+7
| | | | | | | | | | before. We're using a 256-bit PACKUS to do the truncation, but that instruction operates on 128-bit lanes. So previously we shuffled first to rearrange the lanes. But that requires 2 shuffles. Instead we can shuffle after the PACKUS using a single VPERMQ. This matches what our normal LowerTRUNCATE code does when it uses PACKUS. Differential Revision: https://reviews.llvm.org/D51284 llvm-svn: 340757
* [X86] Add support for matching paddus patterns where one of the vectors is a ↵Craig Topper2018-08-271-0/+14
| | | | | | | | | | constant. InstCombine mucks these up a bit. So we need to do some additional pattern matching to fix it. There are a still a few special cases not handled, but this covers the general case. Differential Revision: https://reviews.llvm.org/D50952 llvm-svn: 340756
* Use a lambda for calls to ::open in RetryAfterSignalHans Wennborg2018-08-272-3/+8
| | | | | | | | | | In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing compile errors of RetryAfterSignal due to overload resolution. Wrapping the call in a lambda avoids this. Based on a patch by Chih-Wei Huang <cwhuang@linux.org.tw>! llvm-svn: 340751
* [WebAssembly] Added default stack-only instruction mode for MC.Wouter van Oortmerssen2018-08-279-244/+573
| | | | | | | | | | | | | | | | | | | | | Summary: Made it convert from register to stack based instructions, and removed the registers. Fixes to related code that was expecting register based instructions. Added the correct testing flag to all tests, depending on what the format they were expecting so far. Translated one test to stack format as example: reg-stackify-stack.ll tested: llvm-lit -v `find test -name WebAssembly` unittests/MC/* Reviewers: dschuff, sunfish Subscribers: sbc100, jgravelle-google, eraman, aheejin, llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D51241 llvm-svn: 340750
* fix comment typoNico Weber2018-08-272-2/+2
| | | | llvm-svn: 340744
* [SelectionDAG] add helper query for binops; NFCSanjay Patel2018-08-271-11/+2
| | | | | | We will also use this in a planned enhancement for vector insertelement. llvm-svn: 340741
* [PowerPC] Revert commit r339779Nemanja Ivanovic2018-08-274-9/+16
| | | | | | | This commit has caused failures in some internal benchmarks. Temporarily reverting this patch until the issue can be diagnosed and fixed. llvm-svn: 340740
* [Sparc] Avoid writing outside array in applyFixupDaniel Cederman2018-08-271-3/+17
| | | | | | | | | | | | | | | | Summary: If an object file ends with a relocation that is smaller than 4 bytes we will write outside the Data array and trigger an "Invalid index" assertion. Reviewers: jyknight, venkatra Reviewed By: jyknight Subscribers: fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D50971 llvm-svn: 340736
* [PowerPC] Recommit r340016 after fixing the reported issueNemanja Ivanovic2018-08-274-3/+38
| | | | | | | | The internal benchmark failure reported by Google was due to a missing check for the result type for the sign-extend and shift DAG. This commit adds the check and re-commits the patch. llvm-svn: 340734
* [Sparc] Add support for the cycle counter available in GR740Daniel Cederman2018-08-276-2/+25
| | | | | | | | | | | | | | | | | Summary: The GR740 provides an up cycle counter in the registers ASR22 and ASR23. As these registers can not be read together atomically we only use the value of ASR23 for llvm.readcyclecounter(). The ASR23 register holds the 32 LSBs of the up-counter. Reviewers: jyknight, venkatra Reviewed By: jyknight Subscribers: jfb, fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D48638 llvm-svn: 340733
* [NFC] Split logic of ImplicitControlFlowTracking to allow generalizationMax Kazantsev2018-08-273-94/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | We have a class `ImplicitControlFlowTracking` which allows us to keep track of instructions that can abnormally exit and answer queries like "whether or not there is side-exiting instruction above this instruction in its block". We may want to have the similar tracking for other types of "special" instructions, for example instructions that write memory. This patch separates ImplicitControlFlowTracking into two classes, isolating all general logic not related to implicit control flow into its parent class. We can later make another child of this class to keep track of instructions that write memory. The motivation for that is that we want to make these checks efficiently in the patch https://reviews.llvm.org/D50891. NOTE: The naming of the parent class is not super cool, but the other options we have are hardly better. Please feel free to rename it as NFC if you think you've found a more informative name for it. Differential Revision: https://reviews.llvm.org/D50954 Reviewed By: fedor.sergeev llvm-svn: 340728
OpenPOWER on IntegriCloud