summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [X86][SSE] Allow float domain crossing if we are merging 2 or more shuffles ↵Simon Pilgrim2018-02-161-0/+1
| | | | | | and the root started as a float domain shuffle llvm-svn: 325349
* [PowerPC] Fix transform in table gen file causing UBNemanja Ivanovic2018-02-161-1/+1
| | | | | | | | Running a bootstrap build with UBSan produces a number of instances where we have signed integer overflow due to this transform. Change the type to long to prevent this UB on 64-bit build machines. llvm-svn: 325347
* [mips] Remove codegen support from some 16 bit instructionsSimon Dardis2018-02-161-12/+5
| | | | | | | | | | | | These instructions conflict with their full length variants for the purposes of FastISel as they cannot be distingushed based on the number and type of operands and predicates. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D41285 llvm-svn: 325341
* [SelectionDAG] Add initial SimplifyDemandedVectorElts support for ↵Simon Pilgrim2018-02-161-0/+20
| | | | | | | | simplifying VSELECT operands This just adds a basic pass through - we can add constant selection mask handling in a future patch to fully match InstCombine. llvm-svn: 325338
* [Transforms] Propagate TBAA info in SROAIvan A. Kosarev2018-02-161-22/+61
| | | | | | | | | | | | | | | Now that we have the new TBAA metadata format that is capable of representing accesses to aggregates, we can propagate TBAA access tags from memory setting and transferring intrinsics to load and store instructions and vice versa. Since SROA produces lots of new loads and stores on optimized builds, this change significantly decreases the share of undecorated memory accesses on such builds. Differential Revision: https://reviews.llvm.org/D41563 llvm-svn: 325329
* [ARM] Return true in enableMultipleCopyHints().Jonas Paulsson2018-02-161-0/+1
| | | | | | | | | | Enable multiple COPY hints to eliminate more COPYs during register allocation. Note that this is something all targets should do, see https://reviews.llvm.org/D38128. Review: Eli Friedman llvm-svn: 325327
* [LegalizeDAG] Fix legalization of SETCCMikhail Maltsev2018-02-161-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Currently when expanding a SETCC node into a SELECT_CC, LLVM uses an incorrect type for determining BooleanContent of the result. This patch fixes the issue. Fixes PR36079. Reviewers: rogfer01, javed.absar, efriedma Reviewed By: efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43282 llvm-svn: 325325
* [ARM] Materialise some boolean values to avoid a branchRoger Ferrer Ibanez2018-02-161-10/+89
| | | | | | | | | | | | | This patch combines some cases of ARMISD::CMOV for integers that arise in comparisons of the form a != b ? x : 0 a == b ? 0 : x and that currently (e.g. in Thumb1) are emitted as branches. Differential Revision: https://reviews.llvm.org/D34515 llvm-svn: 325323
* [ThinLTO] Import global variablesEugene Leviant2018-02-162-20/+88
| | | | | | Differential revision: https://reviews.llvm.org/D43077 llvm-svn: 325320
* [X86] Allow CMOVs of constants to be sign extended from i32.Craig Topper2018-02-161-4/+5
| | | | | | Sign extending i32 constants only requires a REX prefix as does widening the CMOV. This is cheaper than the explicit sign extend op. llvm-svn: 325318
* [X86] Don't zero_extend cmov up to i64, stop at i32.Craig Topper2018-02-161-11/+26
| | | | | | Zero extend from i32 to i64 is free. So extend from i16 to i32, and then use a free zero extend to finish. llvm-svn: 325317
* [APInt] Fix extractBits to correctly handle Result.isSingleWord() case.Tim Shen2018-02-161-1/+2
| | | | | | | | | | | | Summary: extractBits assumes that `!this->isSingleWord() implies !Result.isSingleWord()`, which may not necessarily be true. Handle both cases. Reviewers: RKSimon Subscribers: sanjoy, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43363 llvm-svn: 325311
* [GVN] Partially revert debug info salvage change (r325063)Vedant Kumar2018-02-161-1/+0
| | | | | | | | | | | | | In r325063, we salvaged debug values from dying instructions in GVN::processBlock() and GVN::performScalarPRE(). The change in performScalarPRE(), while correct, is unhelpful. It introduced a call to salvageDebugInfo() which was immediately followed by a RAUW, meaning it prevented the RAUW from efficiently updating dbg.value intrinsics. This commit reverts the mistake and tightens up the affected test case. llvm-svn: 325308
* [DCE] Salvage debug info from dead instsVedant Kumar2018-02-151-0/+3
| | | | | | | This results in small increases in the size of the .debug_loc section and the number of unique source variables in a stage2 build of opt. llvm-svn: 325301
* [AMDGPU] Combine adjacent waitcounts in a single strongest waitStanislav Mekhanoshin2018-02-151-7/+44
| | | | | | Differential Revision: https://reviews.llvm.org/D43350 llvm-svn: 325299
* [X86][3DNOW] Teach decoder about AMD 3DNow! instrsRafael Auler2018-02-154-11/+50
| | | | | | | | | | | | | | | | | | | Summary: This patch makes the decoder understand old AMD 3DNow! instructions that have never been properly supported in the X86 disassembler, despite being supported in other subsystems. Hopefully this should make the X86 decoder more complete with respect to binaries containing legacy code. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: llvm-commits, maksfb, bruno Differential Revision: https://reviews.llvm.org/D43311 llvm-svn: 325295
* [X86] Enable BT to be used in place of TEST for single bit checks under optsizeCraig Topper2018-02-151-6/+9
| | | | | | | | We already do this for 64-bit when it won't fit into a 64-bit AND/TEST's immediate field. This adds an additional qualifier to do it for any single bit constant larger than 8-bits under optsize Differential Revision: https://reviews.llvm.org/D43346 llvm-svn: 325290
* [DAGCombiner] Call ExtendUsesToFormExtLoad in (zext (and (load)))->(and ↵Craig Topper2018-02-151-13/+14
| | | | | | | | | | | | | | (zextload)) even when the and does not have multiple uses Same for the sign extend case. Currently we check for multiple uses on the binop. Then we call ExtendUsesToFormExtLoad to capture SetCCs that use the load. So we only end up finding any setccs when the and has additional uses and the load is used by a setcc. I don't think the and having multiple uses is relevant here. I think we should only be checking for the load having multiple uses. This changes an NVPTX test because we now find that the load has a second use by a truncate, but ExtendUsesToFormExtLoad only looks at setccs it can extend. All other operations just check isTruncateFree. Maybe we should allow widening of an existing truncate even if its not free? Differential Revision: https://reviews.llvm.org/D43063 llvm-svn: 325289
* [X86] Use btc/btr/bts to implement xor/and/or that affects a single bit in ↵Craig Topper2018-02-153-1/+37
| | | | | | | | | | | | the upper 32-bits of a 64-bit operation. We can't fold a large immediate into a 64-bit operation. But if we know we're only operating on a single bit we can use the bit instructions. For now only do this for optsize. Differential Revision: https://reviews.llvm.org/D37418 llvm-svn: 325287
* [Coroutines] Don't move stores for allocator argsBrian Gesiak2018-02-151-1/+16
| | | | | | | | | | | | | | | | | | | | | Summary: The behavior described in Coroutines TS `[dcl.fct.def.coroutine]/7` allows coroutine parameters to be passed into allocator functions. The instructions to store values into the alloca'd parameters must not be moved past the frame allocation, otherwise uninitialized values are passed to the allocator. Test Plan: `check-llvm` Reviewers: rsmith, GorNishanov, eric_niebler Reviewed By: GorNishanov Subscribers: compnerd, EricWF, llvm-commits Differential Revision: https://reviews.llvm.org/D43000 llvm-svn: 325285
* [Utils] salvageDI: Add a comment and move a call earlier, NFCVedant Kumar2018-02-151-1/+3
| | | | llvm-svn: 325280
* Silence warning about unused private variable.Zachary Turner2018-02-151-1/+3
| | | | llvm-svn: 325275
* Call FlushFileBuffers on output files.Zachary Turner2018-02-151-1/+15
| | | | | | | | | | | | There is a latent Windows kernel bug, the exact trigger conditions are not well understood, which can cause a file to be correctly written, but unable to be correctly read. The workaround appears to be simply calling FlushFileBuffers. Differential Revision: https://reviews.llvm.org/D42925 llvm-svn: 325274
* Recommit [Hexagon] Make the vararg handling a bit more robustKrzysztof Parzyszek2018-02-151-19/+11
| | | | | | | Use the FunctionType of the callee when it's available. It may not be available for synthetic calls to functions specified by external symbols. llvm-svn: 325269
* bpf: fix a bug in dag2dag optimization for loads from readonly sectionYonghong Song2018-02-151-4/+4
| | | | | | | | | | | | | | | | | | | | | The reference '&' is missing in the function parameter. If there are back-to-back optimizations in terms of dag node list like below: t29: i64,ch = load<LD4[bitcast (%struct.test_t* @test.t to i8*)+12](dereferenceable), zext from i32> t3, t43, undef:i64 t34: i64,ch = load<LD4[bitcast (%struct.test_t* @test.t to i8*)](dereferenceable), zext from i32> t3, t41, undef:i64 The bug will trigger a segfault for the added test case remove_truncate_5.ll: LLVMSymbolizer: error reading file: No such file or directory #0 0x000000000241c4d9 (llc+0x241c4d9) #1 0x000000000241c56a (llc+0x241c56a) #2 0x000000000241aa50 (llc+0x241aa50) ... #22 0x0000000000fd5edf (llc+0xfd5edf) #23 0x00007f0fe03bec05 __libc_start_main (/lib64/libc.so.6+0x21c05) #24 0x0000000000fd3e69 (llc+0xfd3e69) ... Segmentation fault Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 325267
* Revert "[Hexagon] Make the vararg handling a bit more robust"Krzysztof Parzyszek2018-02-151-8/+19
| | | | | | This is breaking lit tests. llvm-svn: 325266
* [InstCombine] use m_OneUse to reduce code; NFCSanjay Patel2018-02-151-2/+2
| | | | llvm-svn: 325263
* [Hexagon] Make the vararg handling a bit more robustKrzysztof Parzyszek2018-02-151-19/+8
| | | | | | | The FunctionType of the callee is always available, even if the Function of the callee is not. Use that to get the number of fixed parameters. llvm-svn: 325259
* [CodeGen] Separate MBB metadata from instructions in -debug printingFrancis Visoiu Mistrih2018-02-151-1/+9
| | | | | | | Add an empty line after 'liveins:', 'successors:', or '; predecessors:', the one that ends up to be the last one. llvm-svn: 325258
* [Hexagon] Fix lowering of formal arguments after r324737Krzysztof Parzyszek2018-02-151-18/+16
| | | | | | Lowering of formal arguments needs to be aware of vararg functions. llvm-svn: 325255
* [SelectionDAG] Pull out repeated Op.getOpcode(). NFCI.Simon Pilgrim2018-02-151-6/+7
| | | | llvm-svn: 325253
* [CodeGen] Print irreducible loop header weight as a MIR commentFrancis Visoiu Mistrih2018-02-151-3/+2
| | | | | | Prefix it with '; ' to make it more MIR-compatible. llvm-svn: 325251
* [InstCombine] allow sin/cos transforms with 'reassoc'Sanjay Patel2018-02-151-2/+1
| | | | | | | | | | | | | | | | The variable name 'AllowReassociate' is a lie at this point because it's set to 'isFast()' which is more than the 'reassoc' FMF after rL317488. In D41286, we showed that this transform may be valid even with strict math by brute force checking every 32-bit float result. There's a potential problem here because we're replacing with a tan() libcall rather than a hypothetical LLVM tan intrinsic. So we might set errno when we should be guaranteed not to do that. But that's independent of this change. llvm-svn: 325247
* [ARM] Allow 64- and 128-bit types with 't' inline asm constraintPablo Barrio2018-02-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In LLVM, 't' selects a floating-point/SIMD register and only supports 32-bit values. This is appropriately documented in the LLVM Language Reference Manual. However, this behaviour diverges from that of GCC, where 't' selects the s0-s31 registers and its qX and dX variants depending on additional operand modifiers (q/P). For example, the following C code: #include <arm_neon.h> float32x4_t a, b, x; asm("vadd.f32 %0, %1, %2" : "=t" (x) : "t" (a), "t" (b)) results in the following assembly if compiled with GCC: vadd.f32 s0, s0, s1 whereas LLVM will show "error: couldn't allocate output register for constraint 't'", since a, b, x are 128-bit variables, not 32-bit. This patch extends the use of 't' to mean that of GCC, thus allowing selection of the lower Q vector regs and their D/S variants. For example, the earlier code will now compile as: vadd.f32 q0, q0, q1 This behaviour still differs from that of GCC but I think it is actually more correct, since LLVM picks up the right register type based on the datatype of x, while GCC would need an extra operand modifier to achieve the same result, as follows: asm("vadd.f32 %q0, %q1, %q2" : "=t" (x) : "t" (a), "t" (b)) Since this is only an extension of functionality, existing code should not be affected by this change. Note that operand modifiers q/P are already supported by LLVM, so this patch should suffice to support inline assembly with constraint 't' originally built for GCC. Reviewers: grosbach, rengolin Reviewed By: rengolin Subscribers: rogfer01, efriedma, olista01, aemerson, javed.absar, eraman, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42962 llvm-svn: 325244
* [X86][SSE] combineTruncateWithSat - use truncateVectorWithPACK to chain ↵Simon Pilgrim2018-02-151-10/+17
| | | | | | | | PACKUS vXi32-vXi8 saturated truncation We can use PACKSS/PACKUS to saturate each stage of the chain: PACKSSDW down to [-32768,32767] and then PACKUSWB to [0,255]. llvm-svn: 325243
* [InstCombine] allow X / C -> X * (1.0/C) for vector splat FP constantsSanjay Patel2018-02-152-11/+20
| | | | llvm-svn: 325237
* [X86][SSE] combineTruncateWithSat - use truncateVectorWithPACK to chain ↵Simon Pilgrim2018-02-151-7/+12
| | | | | | | | | | PACKSS vXi32-vXi8 saturated truncation We can use PACKSS to saturate each stage of the chain: PACKSSDW down to [-32768,32767] and then PACKSSWB to [-128,127]. PACKUS is a little trickier and will be handled in a separate patch. llvm-svn: 325235
* [DebugInfo] Accept enumeration types without underlying integer type present inMomchil Velikov2018-02-151-5/+5
| | | | | | | | | | debug info metadata ... when generating DWARF. Differential Revision: https://reviews.llvm.org/D43304 llvm-svn: 325234
* [SelectionDAG] Add initial implementation of ↵Simon Pilgrim2018-02-152-91/+238
| | | | | | | | | | | | TargetLowering::SimplifyDemandedVectorElts This is mainly a move of simplifyShuffleOperands from DAGCombiner::visitVECTOR_SHUFFLE to create a more general purpose TargetLowering::SimplifyDemandedVectorElts implementation. Further features can be moved/added in future patches. Differential Revision: https://reviews.llvm.org/D42896 llvm-svn: 325232
* [ARM] f16 vcmp fixesSjoerd Meijer2018-02-151-4/+4
| | | | | | | | This adds f16 VCMP match rules and fixes the test cases. Differential Revision: https://reviews.llvm.org/D43291 llvm-svn: 325228
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-1511-52/+19
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Specify namespace for reallocSerge Pavlov2018-02-151-1/+1
| | | | llvm-svn: 325226
* Report fatal error in the case of out of memorySerge Pavlov2018-02-1511-19/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* (NFC)[MachineCombiner] Improve debug output.Andrew V. Tischenko2018-02-151-28/+53
| | | | llvm-svn: 325217
* [NFC] Rename isKnownViaSimpleReasoning to isKnownViaNonRecursiveReasoningMax Kazantsev2018-02-151-15/+15
| | | | llvm-svn: 325216
* [SCEV] Favor isKnownViaSimpleReasoning over constant ranges checkMax Kazantsev2018-02-151-6/+6
| | | | | | | | | | | | | | | | | | | | | There is a more powerful but still simple function `isKnownViaSimpleReasoning ` that does constant range check and few more additional checks. We use it some places (e.g. when proving implications) and in some other places we only check constant ranges. Currently, indvar simplifier fails to remove the check in following loop: int inc = ...; for (int i = inc, j = inc - 1; i < 200; ++i, ++j) if (i > j) { ... } This patch replaces all usages of `isKnownPredicateViaConstantRanges` with `isKnownViaSimpleReasoning` to have smarter proofs. In particular, it fixes the case above. Reviewed-By: sanjoy Differential Revision: https://reviews.llvm.org/D43175 llvm-svn: 325214
* [X86] Change 32 and 64 bit versions of LSL instruction have a 16-bit memory ↵Craig Topper2018-02-151-4/+6
| | | | | | | | operand. This matches the Intel and AMD documentation and is consistent with the LAR instruction. llvm-svn: 325197
* [X86] Dont' allow 'outs' and 'ins' in at&t syntax without suffixes.Craig Topper2018-02-141-6/+6
| | | | | | The match would be ambiguous, but at&t asm parsing doesn't support ambiguous matches and will just return the first. llvm-svn: 325192
* [X86] Reverse the operand order of invlpga in at&t syntax to match gas.Craig Topper2018-02-141-2/+2
| | | | llvm-svn: 325190
* [InstCombine] clean up fold for X / C -> X * (1.0/C); NFCISanjay Patel2018-02-141-34/+27
| | | | | | This should work with vector constants too, but it's currently limited to scalar. llvm-svn: 325187
OpenPOWER on IntegriCloud