summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Add default values for member functions.Richard Trieu2017-11-211-0/+2
| | | | | | | | Initialize IsVis2 and IsVis3 in SparcSubtarget::initializeSubtargetDependencies. MSan detected uninitialized read of IsVis3 after r318704. Initializing the variables to false will prevent undefined behavior. llvm-svn: 318724
* [SCCP] If we replace with a constant, we can't replace with a range.Davide Italiano2017-11-211-1/+3
| | | | | | This microoptimization is NFC. llvm-svn: 318711
* Revert r318678 to fix Clang testRichard Trieu2017-11-215-16/+20
| | | | | | r318678 caused the Clang test CodeGen/ms-inline-asm.c to start failing. llvm-svn: 318710
* [msan] Don't sanitize "nosanitize" instructionsVitaly Buka2017-11-201-2/+14
| | | | | | | | | | Reviewers: eugenis Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40205 llvm-svn: 318708
* [SelectionDAG] When promoting the result of a VSELECT, make sure we promote ↵Craig Topper2017-11-201-3/+2
| | | | | | | | | | | | the condition to the SetCC type for the final result type not the original type. Normally this would be cleaned up by promoting the condition operand next. But in the attached case we promoted the result from v2i48 to v2i64 and the condition from v2i1 to v2i48. Then we tried to "promote" the v2i48 condition back to v2i1 because that's what the SetCC result type for v2i64 is on X86 with VLX. But promote is either a NOP or SIGN_EXTEND and this would need a truncation. With the change here we now get the SetCC type of v2i1 when we're handling the result promotion and the operand no longer needs to be promoted itself. Fixes PR35272. llvm-svn: 318706
* [Sparc] efficient pattern for UINT_TO_FP conversionFedor Sergeev2017-11-203-29/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: while investigating performance degradation of imagick benchmark there were found inefficient pattern for UINT_TO_FP conversion. That pattern causes RAW hazard in assembly code. Specifically, uitofp IR operator results in poor assembler : st %i0, [%fp - 952] ldd [%fp - 952], %f0 it stores 32-bit integer register into memory location and then loads 64-bit floating point data from that location. That is exactly RAW hazard case. To optimize that case it is possible to use SPISD::ITOF and SPISD::XTOF for conversion from integer to floating point data type and to use ISD::BITCAST to copy from integer register into floating point register. The fix is to write custom UINT_TO_FP pattern using SPISD::ITOF, SPISD::XTOF, ISD::BITCAST. Patch by Alexey Lapshin Reviewers: fedor.sergeev, jyknight, dcederman, lero_chris Reviewed By: jyknight Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36875 llvm-svn: 318704
* Add heuristics for irreducible loop metadata under PGOHiroshi Yamauchi2017-11-201-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add the following heuristics for irreducible loop metadata: - When an irreducible loop header is missing the loop header weight metadata, give it the minimum weight seen among other headers. - Annotate indirectbr targets with the loop header weight metadata (as they are likely to become irreducible loop headers after indirectbr tail duplication.) These greatly improve the accuracy of the block frequency info of the Python interpreter loop (eg. from ~3-16x off down to ~40-55% off) and the Python performance (eg. unpack_sequence from ~50% slower to ~8% faster than GCC) due to better register allocation under PGO. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39980 llvm-svn: 318693
* Fix spelling in comment. NFCI.Simon Pilgrim2017-11-201-1/+1
| | | | llvm-svn: 318687
* Revert "[SelectionDAG] Make sorting predicate stronger to remove ↵Mandeep Singh Grang2017-11-201-9/+4
| | | | | | | | | | non-deterministic ordering" This broke the bots. Reverting this until I can fix the failures. This reverts commit 5a3db2856d12a3c4b400f487d39f8f05989e79f0. llvm-svn: 318686
* [AArch64] Adjust the cost model for Exynos M1 and M2Evandro Menezes2017-11-201-2/+4
| | | | | | Fix the modeling of test and branch. llvm-svn: 318685
* Revert "Fix out-of-order stepping behavior in programs with sunk instructions."Paul Robinson2017-11-201-11/+0
| | | | | | | This reverts commit 30419e150cd940893a13b345e85f96053850208f. aka r318679. It caused "sanitizer-windows" bot to fail. llvm-svn: 318684
* [SelectionDAG] Make sorting predicate stronger to remove non-deterministic ↵Mandeep Singh Grang2017-11-201-4/+9
| | | | | | | | | | | | | | | | | | | | ordering Summary: This fixes failures in the following tests uncovered by D39245: LLVM :: CodeGen/ARM/ifcvt3.ll LLVM :: CodeGen/ARM/switch-minsize.ll LLVM :: CodeGen/X86/switch.ll Reviewers: hans, efriedma Reviewed By: hans Subscribers: fhahn, aemerson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D39995 llvm-svn: 318680
* Fix out-of-order stepping behavior in programs with sunk instructions.Paul Robinson2017-11-201-0/+11
| | | | | | | | | | | | | | | | MachineSink attempts to place instructions near the basic blocks where they are needed. Once an instruction has been sunk, its location relative to other instructions is no longer consistent with the original source code. In order to ensure correct single-stepping and profiling, the debug location for sunk instructions is either merged with the insertion point or erased if the target successor block is empty. Patch by Matthew Voss! Differential Revision: https://reviews.llvm.org/D39933 llvm-svn: 318679
* [X86] Avoid unecessary opsize byte in segment move to memoryNirav Dave2017-11-205-20/+16
| | | | | | | | | | | | | | | | | Summary: Segment moves to memory are always 16-bit. Remove invalid 32 and 64 bit variants. Fixes PR34478. Reviewers: rnk, craig.topper Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39847 llvm-svn: 318678
* [SROA] Correctly invalidate analyses when dead instructions deletedTeresa Johnson2017-11-201-2/+5
| | | | | | | | | | | | | | | Summary: SROA can fail in rewriting alloca but still rewrite a phi resulting in dead instruction elimination. The Changed flag was not being set correctly, resulting in downstream passes using stale analyses. The included test case will assert during the second BDCE pass as a result. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39921 llvm-svn: 318677
* [AMDGPU][MC][GFX8][GFX9] Corrected names of integer ↵Dmitry Preobrazhensky2017-11-207-100/+149
| | | | | | | | | | | | v_{add/addc/sub/subrev/subb/subbrev} See bug 34765: https://bugs.llvm.org//show_bug.cgi?id=34765 Reviewers: tamazov, SamWot, arsenm, vpykhtin Differential Revision: https://reviews.llvm.org/D40088 llvm-svn: 318675
* [asan] Use dynamic shadow on 32-bit Android, try 2.Evgeniy Stepanov2017-11-201-11/+63
| | | | | | | | | | | | | | | | Summary: This change reverts r318575 and changes FindDynamicShadowStart() to keep the memory range it found mapped PROT_NONE to make sure it is not reused. We also skip MemoryRangeIsAvailable() check, because it is (a) unnecessary, and (b) would fail anyway. Reviewers: pcc, vitalybuka, kcc Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40203 llvm-svn: 318666
* [MachineCSE] Add new callback for is caller preserved or constant physregsTony Jiang2017-11-202-2/+9
| | | | | | | | | | | | | The instructions addis,addi, bl are used to calculate the address of TLS thread local variables. These TLS access code sequences are generated repeatedly every time the thread local variable is accessed. By communicating to Machine CSE that X2 is guaranteed to have the same value within the same function call (so called Caller Preserved Physical Register), the redundant TLS access code sequences are cleaned up. Differential Revision: https://reviews.llvm.org/D39173 llvm-svn: 318661
* [mips] Reorder target specific passesSimon Dardis2017-11-201-5/+4
| | | | | | | | | Move the hazard scheduling pass to after the long branch pass, as the long branch pass can create forbiddden slot hazards. Rather than complicating the implementation of the long branch pass to handle forbidden slot hazards, just reorder the passes. llvm-svn: 318657
* [SystemZ] Bugfix for handling of subregisters in getRegAllocationHints().Jonas Paulsson2017-11-201-2/+4
| | | | | | | | The 32 bit subreg indices of GR128 registers must also be checked for in getRC32(). Review: Ulrich Weigand. llvm-svn: 318652
* [PPC] Heuristic to choose between a X-Form VSX ld/st vs a X-Form FP ld/st.Tony Jiang2017-11-205-46/+158
| | | | | | | | | | | | | | | | | | | | The VSX versions have the advantage of a full 64-register target whereas the FP ones have the advantage of lower latency and higher throughput. So what we’re after is using the faster instructions in low register pressure situations and using the larger register file in high register pressure situations. The heuristic chooses between the following 7 pairs of instructions. PPC::LXSSPX vs PPC::LFSX PPC::LXSDX vs PPC::LFDX PPC::STXSSPX vs PPC::STFSX PPC::STXSDX vs PPC::STFDX PPC::LXSIWAX vs PPC::LFIWAX PPC::LXSIWZX vs PPC::LFIWZX PPC::STXSIWX vs PPC::STFIWX Differential Revision: https://reviews.llvm.org/D38486 llvm-svn: 318651
* [AArch64][TableGen] Skip tied result operands for InstAliasSander de Smalen2017-11-201-16/+16
| | | | | | | | | | | | | | | | | | | | Summary: This patch fixes an issue so that the right alias is printed when the instruction has tied operands. It checks the number of operands in the resulting instruction as opposed to the alias, and then skips over tied operands that should not be printed in the alias. This allows to generate the preferred assembly syntax for the AArch64 'ins' instruction, which should always be displayed as 'mov' according to the ARM Architecture Reference Manual. Several unit tests have changed as a result, but only to reflect the preferred disassembly. Some other InstAlias patterns (movk/bic/orr) needed a slight adjustment to stop them becoming the default and breaking other unit tests. Please note that the patch is mostly the same as https://reviews.llvm.org/D29219 which was reverted because of an issue found when running TableGen with the Address Sanitizer. That issue has been addressed in this iteration of the patch. Reviewers: rengolin, stoklund, huntergr, SjoerdMeijer, rovka Reviewed By: rengolin, SjoerdMeijer Subscribers: fhahn, aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D40030 llvm-svn: 318650
* AMDGPU: Partial ILP scheduler port from SelectionDAG to SchedulingDAG ↵Valery Pykhtin2017-11-205-4/+431
| | | | | | | | (experimental) Differential revision: https://reviews.llvm.org/D39897 llvm-svn: 318649
* [LV] Model masking in VPlan, introducing VPInstructionsGil Rapaport2017-11-205-126/+641
| | | | | | | | | | | | | | | This patch adds a new abstraction layer to VPlan and leverages it to model the planned instructions that manipulate masks (AND, OR, NOT), introduced during predication. The new VPValue and VPUser classes model how data flows into, through and out of a VPlan, forming the vertices of a planned Def-Use graph. The new VPInstruction class is a generic single-instruction Recipe that models a planned instruction along with its opcode, operands and users. See VectorizationPlan.rst for more details. Differential Revision: https://reviews.llvm.org/D38676 llvm-svn: 318645
* [LV][X86] Support of AVX2 Gathers code generation and update the LV with thisMohammed Agabaria2017-11-205-46/+172
| | | | | | | | | | | | | | | This patch depends on: https://reviews.llvm.org/D35348 Support of pattern selection of masked gathers of AVX2 (X86\AVX2 code gen) Update LoopVectorize to generate gathers for AVX2 processors. Reviewers: delena, zvi, RKSimon, craig.topper, aaboud, igorb Reviewed By: delena, RKSimon Differential Revision: https://reviews.llvm.org/D35772 llvm-svn: 318641
* [IRCE] Smart range intersectionMax Kazantsev2017-11-201-47/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In rL316552, we ban intersection of unsigned latch range with signed range check and vice versa, unless the entire range check iteration space is known positive. It was a correct functional fix that saved us from dealing with ambiguous values, but it also appeared to be a very restrictive limitation. In particular, in the following case: loop: %iv = phi i32 [ 0, %preheader ], [ %iv.next, %latch] %iv.offset = add i32 %iv, 10 %rc = icmp slt i32 %iv.offset, %len br i1 %rc, label %latch, label %deopt latch: %iv.next = add i32 %iv, 11 %cond = icmp i32 ult %iv.next, 100 br it %cond, label %loop, label %exit Here, the unsigned iteration range is `[0, 100)`, and the safe range for range check is `[-10, %len - 10)`. For unsigned iteration spaces, we use unsigned min/max functions for range intersection. Given this, we wanted to avoid dealing with `-10` because it is interpreted as a very big unsigned value. Semantically, range check's safe range goes through unsigned border, so in fact it is two disjoint ranges in IV's iteration space. Intersection of such ranges is not trivial, so we prohibited this case saying that we are not allowed to intersect such ranges. What semantics of this safe range actually means is that we can start from `-10` and go up increasing the `%iv` by one until we reach `%len - 10` (for simplicity let's assume that `%len - 10` is a reasonably big positive value). In particular, this safe iteration space includes `0, 1, 2, ..., %len - 11`. So if we were able to return safe iteration space `[0, %len - 10)`, we could safely intersect it with IV's iteration space. All values in this range are non-negative, so using signed/unsigned min/max for them is unambiguous. In this patch, we alter the algorithm of safe range calculation so that it returnes a subset of the original safe space which is represented by one continuous range that does not go through wrap. In order to reach this, we use modified SCEV substraction function. It can be imagined as a function that substracts by `1` (or `-1`) as long as the further substraction does not cause a wrap in IV iteration space. This allows us to perform IRCE in many situations when we deal with IV space and range check of different types (in terms of signed/unsigned). We apply this approach for both matching and not matching types of IV iteration space and the range check. One implication of this is that now IRCE became smarter in detection of empty safe ranges. For example, in this case: loop: %iv = phi i32 [ %begin, %preheader ], [ %iv.next, %latch] %iv.offset = sub i32 %iv, 10 %rc = icmp ult i32 %iv.offset, %len br i1 %rc, label %latch, label %deopt latch: %iv.next = add i32 %iv, 11 %cond = icmp i32 ult %iv.next, 100 br it %cond, label %loop, label %exit If `%len` was less than 10 but SCEV failed to trivially prove that `%begin - 10 >u %len- 10`, we could end up executing entire loop in safe preloop while the main loop was still generated, but never executed. Now, cutting the ranges so that if both `begin - 10` and `%len - 10` overflow, we have a trivially empty range of `[0, 0)`. This in some cases prevents us from meaningless optimization. Differential Revision: https://reviews.llvm.org/D39954 llvm-svn: 318639
* [CGP] Fix the crash caused by enable of complex addr modeSerguei Katkov2017-11-201-9/+5
| | | | | | | | | | | | | We must collect all AddModes even if they are the same. This is due to Original value is different but we need all original values collected as they are used as anchors in common phi finding. Reviewers: john.brawn, reames Reviewed By: john.brawn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40166 llvm-svn: 318638
* [X86] clzero check in getHostCPUFeatures should use getX86CpuIDAndInfo not ↵Craig Topper2017-11-191-1/+1
| | | | | | | | getX86CpuIDAndInfoEx. This leaf doesn't take an additional argument. llvm-svn: 318634
* [X86] Reorder and reformat the feature bit checks in getHostCPUFeatues to ↵Craig Topper2017-11-191-54/+50
| | | | | | keep the bits in order per register and encourage future additions to be in order too. llvm-svn: 318633
* [LibCallSimplifier] allow splat vectors for pow(x, 0.5) -> sqrt() transformsSanjay Patel2017-11-191-8/+7
| | | | llvm-svn: 318629
* [LibCallSimplifier] partly fix pow(x, 0.5) -> sqrt() transformsSanjay Patel2017-11-191-32/+49
| | | | | | | | | | | | | | As the first test shows, we could transform an llvm intrinsic which never sets errno into a libcall which could set errno (even though it's marked readnone?), so that's not ideal. It's possible that we can also transform a libcall which could set errno to an intrinsic given the fast-math-flags constraint, but that's deferred to determine exactly which set of FMF are needed. Differential Revision: https://reviews.llvm.org/D40150 llvm-svn: 318628
* [InstSimplify] fold and/or of fcmp ord/uno when operand is known nnanSanjay Patel2017-11-191-9/+51
| | | | | | | | | | | | | | | | | | | The 'ord' and 'uno' predicates have a logic operation for NAN built into their definitions: FCMP_ORD = 7, ///< 0 1 1 1 True if ordered (no nans) FCMP_UNO = 8, ///< 1 0 0 0 True if unordered: isnan(X) | isnan(Y) So we can simplify patterns like this: (fcmp ord (known NNAN), X) && (fcmp ord X, Y) --> fcmp ord X, Y (fcmp uno (known NNAN), X) || (fcmp uno X, Y) --> fcmp uno X, Y It might be better to split this into (X uno 0) | (Y uno 0) as a canonicalization, but that would be another patch. Differential Revision: https://reviews.llvm.org/D40130 llvm-svn: 318627
* [X86] Add test cases for rndscaless/sd intrinsics.Craig Topper2017-11-191-1/+1
| | | | | | Also fix the memop in the ins for these instructions. Not sure what effect this has. llvm-svn: 318624
* [X86] Improve load folding of scalar rcp28 and rsqrt28 instructions using ↵Craig Topper2017-11-191-3/+2
| | | | | | sse_load_f32/f64. llvm-svn: 318623
* [bpf] remove unused variableAlexei Starovoitov2017-11-191-1/+0
| | | | | Signed-off-by: Alexei Starovoitov <ast@kernel.org> llvm-svn: 318615
* [bpf] allow direct and indirect callsAlexei Starovoitov2017-11-195-8/+25
| | | | | | | | | | | | | | | kernel verifier is becoming smarter and soon will support direct and indirect function calls. Remove obsolete error from BPF backend. Make call to use PCRel_4 fixup. 'bpf to bpf' calls are distinguished from 'bpf to kernel' calls by insn->src_reg == BPF_PSEUDO_CALL == 1 which is used as relocation indicator similar to ld_imm64->src_reg == BPF_PSEUDO_MAP_FD == 1 The actual 'call' instruction remains the same for both 'bpf to kernel' and 'bpf to bpf' calls. Signed-off-by: Alexei Starovoitov <ast@kernel.org> llvm-svn: 318614
* [X86] Switch cannonlake to use the SkylakeServer scheduling model instead of ↵Craig Topper2017-11-191-1/+1
| | | | | | | | Haswell. Cannonlake comes after skylake and supports avx512 so this is probably a closer model for now. llvm-svn: 318613
* [X86] Add skeleton support for icelake CPU.Craig Topper2017-11-192-1/+14
| | | | | | There are several patches out for review right now to implement Icelake features. This adds a CPU to collect them under. llvm-svn: 318612
* [X86] Fix 80 column violation and remove trailing whitespace. NFCCraig Topper2017-11-191-7/+8
| | | | llvm-svn: 318611
* Fix use of config.h in public headers.Eric Fiselier2017-11-181-0/+1
| | | | | | | | | | | | | The CodeGenCoverage.h header is installed, but it references the build-only header "llvm/Config/config.h". This breaks use of the CodeGenCoverage.h header once it is installed, because config.h isn't available. This patch fixes the error by moving the config.h include from the CodeGenCoverage.h header (where it's not needed), to the CodeGenCoverage.cpp source file. llvm-svn: 318602
* [X86] Simplify the gather/scatter isel predicates.Craig Topper2017-11-181-54/+27
| | | | | | We don't need a dyn_cast, the predicate already specified the base node. We only need to check the type of the index, the base ptr is guaranteed to be scalar. llvm-svn: 318596
* [X86] Qualify a few places with ExperimentalVectorWideningLegalization.Craig Topper2017-11-181-4/+8
| | | | | | I'm playing around with this flag and these places cause errors if not qualified. llvm-svn: 318595
* [X86] Add todo comment for TRUNC(SUB(X,C)) -> SUB(TRUNC(X),C')Simon Pilgrim2017-11-181-0/+1
| | | | | | As discussed on PR35295, but it causes regressions in combineSubToSubus which need to be addressed first llvm-svn: 318594
* [CallSiteSplitting] Remove some indirection (NFC).Florian Hahn2017-11-181-103/+85
| | | | | | | | | | | | | | | | Summary: With this patch I tried to reduce the complexity of the code sightly, by removing some indirection. Please let me know what you think. Reviewers: junbuml, mcrosier, davidxl Reviewed By: junbuml Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40037 llvm-svn: 318593
* [X86] Output cfi directives for saved XMM registers even if no GPRs are savedMartin Storsjo2017-11-181-2/+1
| | | | | | | | | | This makes sure that functions that only clobber xmm registers (on win64) also get the right cfi directives, if dwarf exceptions are enabled. Differential Revision: https://reviews.llvm.org/D40191 llvm-svn: 318591
* [X86] Fix typo in variable name. NFCCraig Topper2017-11-181-4/+4
| | | | llvm-svn: 318590
* [AArch64] Map G_LOAD on FPR when the definition goes to a copy to FPRQuentin Colombet2017-11-181-2/+11
| | | | | | | | | We used to detect loads feeding fp instructions, but we were failing to take into account cases where this happens through copies. For instance, loads can fed copies coming from the ABI lowering of floating point arguments/results. llvm-svn: 318589
* [AArch64] Map G_STORE on FPR when the source comes from a FPR copyQuentin Colombet2017-11-181-1/+9
| | | | | | | | | We used to detect that stores were fed by fp instructions, but we were failing to take into account cases where this happens through copies. For instance, stores can be fed by copies coming from the ABI lowering of floating point arguments. llvm-svn: 318588
* [RegisterBankInfo] Relax the assert of having matching type sizes on default ↵Quentin Colombet2017-11-181-1/+5
| | | | | | | | | | | | | | | | | | mappings Instead of asserting that the type sizes are exactly equal, we check that the new size is big enough to contain the original type. We have to relax this constrain because, right now, we sometimes specify that things that are smaller than a storage type are legal instead of widening everything to the size of a storage type. E.g., we say that G_AND s16 is legal and we map that on GPR32. This is something we may revisit in the future (either by changing the legalization process or keeping track separately of the storage size and the size of the type), but let us reflect the reality of the situation for now. llvm-svn: 318587
* [AArch64][RegisterBankInfo] Teach instruction mapping about gpr32 -> fpr16 ↵Quentin Colombet2017-11-181-4/+5
| | | | | | | | | cross copies Turns out this copies can actually occur because of the way we lower the ABI for half. llvm-svn: 318586
OpenPOWER on IntegriCloud