summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* TargetMachine: Add address space to getPointerSizeMatt Arsenault2018-03-143-6/+8
| | | | llvm-svn: 327467
* [DAGCombiner] Allow visitEXTRACT_SUBVECTOR to combine with BUILD_VECTORS ↵Craig Topper2018-03-131-1/+1
| | | | | | | | between LegalizeVectorOps and LegalizeDAG. BUILD_VECTORs aren't themselves legalized until LegalizeDAG so we should still be able to create an "illegal" one before that. This helps combine with BUILD_VECTORS that are introduced during LegalizeVectorOps due to unrolling. llvm-svn: 327446
* [MIR] Allow frame-setup and frame-destroy on the same instructionFrancis Visoiu Mistrih2018-03-133-7/+9
| | | | | | | | | | | | | | | Nothing prevents us from having both frame-setup and frame-destroy on the same instruction. When merging: * frame-setup OPCODE1 * frame-destroy OPCODE2 into * frame-setup frame-destroy OPCODE3 we want to be able to print and parse both flags. llvm-svn: 327442
* [DAGCombine] visitREM - Don't assume that one divrem isn't driving anotherSimon Pilgrim2018-03-131-3/+3
| | | | | | | | | | | Under some circumstances the divrems won't have been combined together before getting to this code. So replace the assertion with a if() guard to not expand to X-((X/C)*C) to give the other combine chance to happen. Reduced from OSS-Fuzz #6883 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6883 llvm-svn: 327424
* [SelectionDAGBuilder] Replace deprecated calls to ↵Daniel Neilson2018-03-131-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MemoryIntrinsic::getAlignment() (NFCI) 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 SelectionDAGBuilder to cease using the old getAlignment() API of MemoryIntrinsic in favour of getting source & dest specific alignments through the new API. 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, rL324653, rL324654, rL324773, rL324774, rL324781, rL324784, rL324955, rL324960, rL325816, rL327398 ) 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: 327421
* [MC] Move the reciprocal throughput computation from TargetSchedModel to ↵Andrea Di Biagio2018-03-131-29/+4
| | | | | | | | | | | | | | MCSchedModel. The goal is to make the reciprocal throughput computation accessible through the MCSchedModel interface. This is particularly important for llvm-mca because it can only query the MCSchedModel interface. No functional change intended. Differential Revision: https://reviews.llvm.org/D44392 llvm-svn: 327420
* Revert r327397 [CodeView] Omit forward references for unnamed structs and ...Brock Wyma2018-03-131-40/+10
| | | | | | This reverts commit r327397 to investigate a buildbot failure. llvm-svn: 327414
* [MC] Move the instruction latency computation from TargetSchedModel to ↵Andrea Di Biagio2018-03-131-9/+1
| | | | | | | | | | | | | | | MCSchedModel. The goal is to make the latency information accessible through the MCSchedModel interface. This is particularly important for tools like llvm-mca that only have access to the MCSchedModel API. This partially fixes PR36676. No functional change intended. Differential Revision: https://reviews.llvm.org/D44383 llvm-svn: 327406
* [CodeView] Omit forward references for unnamed structs and unionsBrock Wyma2018-03-131-10/+40
| | | | | | | | | | Codeview references to unnamed structs and unions are expected to refer to the complete type definition instead of a forward reference so Visual Studio can resolve the type properly. Differential Revision: https://reviews.llvm.org/D32498 llvm-svn: 327397
* [CodeGenPrepare] Respect endianness in splitMergedValStore.Jonas Paulsson2018-03-131-1/+2
| | | | | | | | | | | | | splitMergedValStore will split a store into two if target prefers this, or if -force-split-store is passed. This patch adds the missing handling for endianness in this function along with a test case. Review: Eli Friedman https://reviews.llvm.org/D44396 llvm-svn: 327375
* [LegalizeTypes] In SplitVecOp_TruncateHelper, use GetSplitVector on the ↵Craig Topper2018-03-131-2/+2
| | | | | | input instead of creating new extract_subvectors. llvm-svn: 327355
* [SelectionDAG] Improve handling of dangling debug infoBjorn Pettersson2018-03-126-58/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: 1) Make sure to discard dangling debug info if the variable (or variable fragment) is mapped to something new before we had a chance to resolve the dangling debug info. 2) When resolving debug info, make sure to bump the associated SDNodeOrder to ensure that the DBG_VALUE is emitted after the instruction that defines the value used in the DBG_VALUE. This will avoid a debug-use before def scenario as seen in https://bugs.llvm.org/show_bug.cgi?id=36417. The new test case, test/DebugInfo/X86/sdag-dangling-dbgvalue.ll, show some other limitations in how dangling debug info is handled in the SelectionDAG. Since we currently only support having one dangling dbg.value per Value, we will end up dropping debug info when there are more than one variable that is described by the same "dangling value". Reviewers: aprantl Reviewed By: aprantl Subscribers: aprantl, eraman, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44369 llvm-svn: 327303
* [CGP] Fix the remove of matched phis in complex addressing modeSerguei Katkov2018-03-121-1/+13
| | | | | | | | | | | | | | | | | | When we replace the Phi we created with matched ones it is possible that there are two identical phi nodes in IR. And matcher is smart enough to find that new created phi matches both of them. So we try to replace our phi node with matched ones twice and what is bad we delete our phi node twice causing a crash. As soon as we found that we have two identical Phi nodes it makes sense to do a clean-up and replace one phi node by other one. The patch implements it. Reviewers: john.brawn, reames Reviewed By: john.brawn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43758 llvm-svn: 327250
* [TargetSchedule] Minor refactor in computeInstrLatency. NFCAndrea Di Biagio2018-03-111-6/+4
| | | | | | | | The intent of revision r300311 was to add a check for invalid scheduling class descriptors. However, it ended up adding a redundant call in a basic block that should not be reachable. llvm-svn: 327231
* Revert: r327172 "Correct load-op-store cycle detection analysis"Nirav Dave2018-03-101-168/+227
| | | | | | | | | | r327171 "Improve Dependency analysis when doing multi-node Instruction Selection" r328170 "[DAG] Enforce stricter NodeId invariant during Instruction selection" Reverting patch as NodeId invariant change is causing pathological increases in compile time on PPC llvm-svn: 327197
* [TwoAddressInstructionPass] Improve tryInstructionCommute of X86 FMA and ↵Craig Topper2018-03-091-5/+14
| | | | | | | | | | vpternlog instructions These instructions have 3 operands that can be commuted. The first commute we find may not be the best. So we should keep searching if we performed an aggressive commute. There may still be an operand that is killed or a physical register constraint that might be better. Differential Revision: https://reviews.llvm.org/D44324 llvm-svn: 327188
* [TargetLowering] Remove redundant term in two ifs in SimplifySetCC. NFCCraig Topper2018-03-091-2/+2
| | | | | | If we get into the right hand side of the OR, we know that isOpaque is true since the left hand size is just a check that it's false. llvm-svn: 327179
* Improve Dependency analysis when doing multi-node Instruction SelectionNirav Dave2018-03-091-215/+76
| | | | | | | | | | | | | | | | | | | | Relanding after fixing NodeId Invariant. Cleanup cycle/validity checks in ISel (IsLegalToFold, HandleMergeInputChains) and X86 (isFusableLoadOpStore). Now do a full search for cycles / dependencies pruning the search when topological property of NodeId allows. As part of this propogate the NodeId-based cutoffs to narrow hasPreprocessorHelper searches. Reviewers: craig.topper, bogner Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D41293 llvm-svn: 327171
* [DAG] Enforce stricter NodeId invariant during Instruction selectionNirav Dave2018-03-091-13/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instruction Selection makes use of the topological ordering of nodes by node id (a node's operands have smaller node id than it) when doing cycle detection. During selection we may violate this property as a selection of multiple nodes may induce a use dependence (and thus a node id restriction) between two unrelated nodes. If a selected node has an unselected successor this may allow us to miss a cycle in detection an invalid selection. This patch fixes this by marking all unselected successors of a selected node have negated node id. We avoid pruning on such negative ids but still can reconstruct the original id for pruning. In-tree targets have been updated to replace DAG-level replacements with ISel-level ones which enforce this property. This preemptively fixes PR36312 before triggering commit r324359 relands Reviewers: craig.topper, bogner, jyknight Subscribers: arsenm, nhaehnle, javed.absar, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43198 llvm-svn: 327170
* Make early exit hasPredecessorHelper return true. NFCI.Nirav Dave2018-03-091-5/+1
| | | | | | | All uses conservatively assume in early exit case that it will be a predecessor. Changing default removes checking code in all uses. llvm-svn: 327169
* Use branch funnels for virtual calls when retpoline mitigation is enabled.Peter Collingbourne2018-03-091-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The retpoline mitigation for variant 2 of CVE-2017-5715 inhibits the branch predictor, and as a result it can lead to a measurable loss of performance. We can reduce the performance impact of retpolined virtual calls by replacing them with a special construct known as a branch funnel, which is an instruction sequence that implements virtual calls to a set of known targets using a binary tree of direct branches. This allows the processor to speculately execute valid implementations of the virtual function without allowing for speculative execution of of calls to arbitrary addresses. This patch extends the whole-program devirtualization pass to replace certain virtual calls with calls to branch funnels, which are represented using a new llvm.icall.jumptable intrinsic. It also extends the LowerTypeTests pass to recognize the new intrinsic, generate code for the branch funnels (x86_64 only for now) and lay out virtual tables as required for each branch funnel. The implementation supports full LTO as well as ThinLTO, and extends the ThinLTO summary format used for whole-program devirtualization to support branch funnels. For more details see RFC: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120672.html Differential Revision: https://reviews.llvm.org/D42453 llvm-svn: 327163
* Avoid creating a Constant for each value in a ConstantDataSequential.Alina Sbirlea2018-03-091-9/+14
| | | | | | | | | | | | Summary: We create a ConstantDataSequential (ConstantDataArray or ConstantDataVector) to avoid creating a Constant for each element in an array of constants. But them in AsmPrinter, we do create a ConstantFP for each element in the ConstantDataSequential. This triggers excessive memory use when generating large global FP constants. Reviewers: bogner, lhames, t.p.northover Subscribers: jlebar, sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D44277 llvm-svn: 327161
* [GISel]: Add helpers for easy building G_FCONSTANT along with matchersAditya Nandakumar2018-03-092-0/+22
| | | | | | | | | | | | | | | | | | Added helpers to build G_FCONSTANT, along with matching ConstantFP and unit tests for the same. Sample usage. auto MIB = Builder.buildFConstant(s32, 0.5); // Build IEEESingle For Matching the above const ConstantFP* Tmp; mi_match(DstReg, MRI, m_GFCst(Tmp)); https://reviews.llvm.org/D44128 reviewed by: volkan llvm-svn: 327152
* [x86][aarch64] ask the backend whether it has a vector blend instructionSebastian Pop2018-03-091-24/+26
| | | | | | | | | | | | | The code to match and produce more x86 vector blends was enabled for all architectures even though the transform may pessimize the code for other architectures that do not provide a vector blend instruction. Added an aarch64 testcase to check that a VZIP instruction is generated instead of byte movs. Differential Revision: https://reviews.llvm.org/D44118 llvm-svn: 327132
* Propagate flags to SDValue in SplitVecOp_VECREDUCESameer AbuAsal2018-03-081-2/+2
| | | | | | | | | | | | This patch is a fix for PR36642. While legalizing long vector types, make sure the smaller types get the flags of the wider type. bugzilla link: https://bugs.llvm.org/show_bug.cgi?id=36642 Change-Id: I0c2829639f094c862c10a6b51b342d4c2563e1fa llvm-svn: 327079
* [DebugInfo] Add DW_AT_byte_size to vectorsMatt Davis2018-03-081-1/+32
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the DW_AT_byte_size dwarf attribute to vectors. This fixes PR21924 LLVM will round a vector up to the next alignable address, which can result in the vector's representation in the object file being larger than what the debugger will calculate via NumberOfElements * ElementSize. In such a case calling sizeof(MyVec) in the source will result in a different value than what a debugger might present. This situation can occur because LLVM permits non-power of two 'vector_size' attributes. Reviewers: echristo, dexonsmith, aprantl Reviewed By: aprantl Subscribers: probinson, aprantl, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44048 llvm-svn: 327072
* [TargetLowering] Remove redundant if condition in SimplifySetcc. NFCCraig Topper2018-03-081-1/+1
| | | | | | We were checking the condition code a second time when we were already in a block with this same condition code check. llvm-svn: 327069
* [Pipeliner] Fixed node order issue related to zero latency edgesRoorda, Jan-Willem2018-03-071-22/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A desired property of the node order in Swing Modulo Scheduling is that for nodes outside circuits the following holds: none of them is scheduled after both a successor and a predecessor. We call node orders that meet this property valid. Although invalid node orders do not lead to the generation of incorrect code, they can cause the pipeliner not being able to find a pipelined schedule for arbitrary II. The reason is that after scheduling the successor and the predecessor of a node, no room may be left to schedule the node itself. For data flow graphs with 0-latency edges, the node ordering algorithm of Swing Modulo Scheduling can generate such undesired invalid node orders. This patch fixes that. In the remainder of this commit message, I will give an example demonstrating the issue, explain the fix, and explain how the the fix is tested. Consider, as an example, the following data flow graph with all edge latencies 0 and all edges pointing downward. ``` n0 / \ n1 n3 \ / n2 | n4 ``` Consider the implemented node order algorithm in top-down mode. In that mode, the algorithm orders the nodes based on greatest Height and in case of equal Height on lowest Movability. Finally, in case of equal Height and Movability, given two nodes with an edge between them, the algorithm prefers the source-node. In the graph, for every node, the Height and Movability are equal to 0. As will be explained below, the algorithm can generate the order n0, n1, n2, n3, n4. So, node n3 is scheduled after its predecessor n0 and after its successor n2. The reason that the algorithm can put node n2 in the order before node n3, even though they have an edge between them in which node n3 is the source, is the following: Suppose the algorithm has constructed the partial node order n0, n1. Then, the nodes left to be ordered are nodes n2, n3, and n4. Suppose that the while-loop in the implemented algorithm considers the nodes in the order n4, n3, n2. The algorithm will start with node n4, and look for more preferable nodes. First, node n4 will be compared with node n3. As the nodes have equal Height and Movability and have no edge between them, the algorithm will stick with node n4. Then node n4 is compared with node n2. Again the Height and Movability are equal. But, this time, there is an edge between the two nodes, and the algorithm will prefer the source node n2. As there are no nodes left to compare, the algorithm will add node n2 to the node order, yielding the partial node order n0, n1, n2. In this way node n2 arrives in the node-order before node n3. To solve this, this patch introduces the ZeroLatencyHeight (ZLH) property for nodes. It is defined as the maximum unweighted length of a path from the given node to an arbitrary node in which each edge has latency 0. So, ZLH(n0)=3, ZLH(n1)=ZLH(n3)=2, ZLH(n2)=1, and ZLH(n4)=0 In this patch, the preference for a greater ZeroLatencyHeight is added in the top-down mode of the node ordering algorithm, after the preference for a greater Height, and before the preference for a lower Movability. Therefore, the two allowed node-orders are n0, n1, n3, n2, n4 and n0, n3, n1, n2, n4. Both of them are valid node orders. In the same way, the bottom-up mode of the node ordering algorithm is adapted by introducing the ZeroLatencyDepth property for nodes. The patch is tested by adding extra checks to the following existing lit-tests: test/CodeGen/Hexagon/SUnit-boundary-prob.ll test/CodeGen/Hexagon/frame-offset-overflow.ll test/CodeGen/Hexagon/vect/vect-shuffle.ll Before this patch, the pipeliner failed to pipeline the loops in these tests due to invalid node-orders. After the patch, the pipeliner successfully pipelines all these loops. Reviewers: bcahoon Reviewed By: bcahoon Subscribers: Ayal, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D43620 llvm-svn: 326925
* Revert "Reapply "[DWARFv5] Emit file 0 to the line table.""Alexander Kornienko2018-03-073-12/+9
| | | | | | | | | | | | | | | | This reverts commit r326839. r326839 breaks assembly file parsing: $ cat q.c void g() {} $ clang -S q.c -g $ clang -g -c q.s q.s:9:2: error: file number already allocated .file 1 "/tmp/test" "q.c" ^ llvm-svn: 326902
* Reapply "[DWARFv5] Emit file 0 to the line table."Paul Robinson2018-03-063-9/+12
| | | | | | | | Fixes the bug found by asan. Also XFAIL the new test for Darwin, which is stuck on DWARF v2, and fix up other tests so they stop failing on Windows. llvm-svn: 326839
* [TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorEltsSimon Pilgrim2018-03-061-0/+68
| | | | | | | | Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
* [CodeView] Emit UdtSourceLine information for enumsAaron Smith2018-03-062-13/+29
| | | | | | | | | | | | | | | | | Summary: - Emit UdtSourceLine information for enums to match MSVC - Add a method to add UDTSrcLine and call it for all Class/Struct/Union/Enum - Update test cases to verify the changes Reviewers: zturner, llvm-commits, rnk Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D44116 llvm-svn: 326824
* [Pipeliner] Test commit: fixed spelling mistake in commentsRoorda, Jan-Willem2018-03-061-1/+1
| | | | | | | | | | Reviewers: bcahoon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44152 llvm-svn: 326808
* test commit: fix typo in comment Simi Pallipurath2018-03-061-1/+1
| | | | | | This is a simple change to do the test commit and verify commit access. llvm-svn: 326800
* Fixup for rL326769 (RegState::Debug is being truncated to a bool)Bjorn Pettersson2018-03-061-2/+5
| | | | | | | | | I obviously messed up arguments to MachineOperand::CreateReg in rL326769. This should make it work as intended. Thanks to RKSimon for spotting this. llvm-svn: 326780
* [DebugInfo] Discard invalid DBG_VALUE instructions in LiveDebugVariablesBjorn Pettersson2018-03-061-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a workaround for pr36417 https://bugs.llvm.org/show_bug.cgi?id=36417 LiveDebugVariables will now verify that the DBG_VALUE instructions are sane (prior to register allocation) by asking LIS if a virtual register used in the DBG_VALUE is live (or dead def) in the slot index before the DBG_VALUE. If it isn't sane the DBG_VALUE is discarded. One pass that was identified as introducing non-sane DBG_VALUE instructtons, when analysing pr36417, was the DAG->DAG Instruction Selection. It sometimes inserts DBG_VALUE instructions referring to a virtual register that is defined later in the same basic block. So it is a use before def kind of problem. The DBG_VALUE is typically inserted in the beginning of a basic block when this happens. The problem can be seen in the test case test/DebugInfo/X86/dbg-value-inlined-parameter.ll Reviewers: aprantl, rnk, probinson Reviewed By: aprantl Subscribers: vsk, davide, alexcrichton, Ka-Ka, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D43956 llvm-svn: 326769
* Revert "[DWARFv5] Emit file 0 to the line table."Paul Robinson2018-03-063-12/+9
| | | | | | | | | Caused an asan failure. This reverts commit d54883f081186cdcce74e6f98cfc0438579ec019. aka r326758 llvm-svn: 326762
* [DWARFv5] Emit file 0 to the line table.Paul Robinson2018-03-063-9/+12
| | | | | | | | | | | DWARF v5 specifies that the root file (also given in the DW_AT_name attribute of the compilation unit DIE) should be emitted explicitly to the line table's list of files. This makes the line table more independent of the .debug_info section. Differential Revision: https://reviews.llvm.org/D44054 llvm-svn: 326758
* GlobalISel: IRTranslate llvm.fabs.* intrinsicVolkan Keles2018-03-051-0/+5
| | | | | | | | | | | | | | | | Summary: Fabs is a common floating-point operation, especially for some expansions. This patch adds a new generic opcode for llvm.fabs.* intrinsic in order to avoid building/matching this intrinsic. Reviewers: qcolombet, aditya_nandakumar, dsanders, rovka Reviewed By: aditya_nandakumar Subscribers: kristof.beyls, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D43864 llvm-svn: 326749
* Fix an unused variable warning introduced by rr326703. NFCEric Liu2018-03-051-1/+3
| | | | llvm-svn: 326732
* [MachineScheduler] Dump SUnits before calling SchedImpl->initialize()Jonas Paulsson2018-03-051-4/+4
| | | | | | | | | | | | | | | This is a NFC simple patch that changes the DEBUG dumping in the MachineScheduler so that the dumping of the built SUnits is done before the SchedImpl->initialize() is called. This is better on SystemZ, since it has a strategy that does some dumping at the start of the region, and it is not possible to easily read it if it is output above a long list of SU. Review: Javed Absar https://reviews.llvm.org/D44089 llvm-svn: 326716
* Pass Divergence Analysis data to Selection DAG to drive divergenceAlexander Timofeev2018-03-054-5/+135
| | | | | | | | dependent instruction selection. Differential revision: https://reviews.llvm.org/D35267 llvm-svn: 326703
* [DAGCombiner] Add a peekThroughBitcast to MergeStoresOfConstantsOrVecElts to ↵Craig Topper2018-03-041-0/+1
| | | | | | | | fix a crash if we are storing a bitcast of a constant. Loading a constant into a k-register in AVX512 requires a bitcast from a scalar constant. In the test case here we have a k-register store that gets split into multiple parts of KNL. MergeConsecutiveStores sees each of these pieces as a consecutive store and looks through the bitcast to find the underly scalar constant. But when we went to create the combined store we didn't look through the same bitcast. llvm-svn: 326677
* [LegalizeVectorTypes] When scalarizing the operand of a unary op like TRUNC, ↵Craig Topper2018-03-021-1/+1
| | | | | | | | | | | | use a SCALAR_TO_VECTOR rather than a single element BUILD_VECTOR to convert back to a vector type. X86 considers v1i1 a legal type under AVX512 and as such a truncate from a v1iX type to v1i1 can be turned into a scalar truncate plus a conversion to v1i1. We would much prefer a v1i1 SCALAR_TO_VECTOR over a one element BUILD_VECTOR. During lowering we were detecting the v1i1 BUILD_VECTOR as a splat BUILD_VECTOR like we try to do for v2i1/v4i1/etc. In this case we create (select i1 splat_elt, v1i1 all-ones, v1i1 all-zeroes). That goes through some more legalization and we end up with a CMOV choosing between 0 and 1 in scalar and a scalar_to_vector. Arguably we could detect the v1i1 BUILD_VECTOR and do this better in X86 target code. But just using a SCALAR_TO_VECTOR in legalization is much easier. llvm-svn: 326637
* Add DBG_VALUE support to the linear DAG schedulerAdrian Prantl2018-03-021-1/+14
| | | | | | | | | | | The fast/linear DAG scheduler doesn't lower DBG_VALUEs except for function entry nodes. Patch by Joshua Cranmer! Differential Revision: https://reviews.llvm.org/D43028 llvm-svn: 326631
* [MergeICmps] Revert 324317 "Enable the MergeICmps Pass by default."Clement Courbet2018-03-021-4/+5
| | | | | | While working on PR36557. llvm-svn: 326575
* [LV][CFG] Add irreducible CFG detection for outer loopsFlorian Hahn2018-03-021-36/+3
| | | | | | | | | | | | | | | | This patch adds support for detecting outer loops with irreducible control flow in LV. Current detection uses SCCs and only works for innermost loops. This patch adds a utility function that works on any CFG, given its RPO traversal and its LoopInfoBase. This function is a generalization of isIrreducibleCFG from lib/CodeGen/ShrinkWrap.cpp. The code in lib/CodeGen/ShrinkWrap.cpp is also updated to use the new generic utility function. Patch by Diego Caballero <diego.caballero@intel.com> Differential Revision: https://reviews.llvm.org/D40874 llvm-svn: 326568
* [DAGCombiner] When combining zero_extend of a truncate, only mask before ↵Craig Topper2018-03-011-1/+1
| | | | | | | | | | extending for vectors. Masking first, prevents the extend from being combine with loads. Its also interfering with some vXi1 extraction code. Differential Revision: https://reviews.llvm.org/D42679 llvm-svn: 326500
* [SelectionDAG] Support some SimplifySetCC cases for comparing against vector ↵Craig Topper2018-03-011-3/+6
| | | | | | | | | | | | | | splats of constants. This supports things like (setcc ugt X, 0) -> (setcc ne X, 0) I've restricted to only make changes to vectors before legalize ops because I doubt all targets have accurate condition code legality information for vectors given how little we did before. Differential Revision: https://reviews.llvm.org/D42948 llvm-svn: 326495
* Revert "[DEBUGINFO] Add flag for DWARF2 or less to use sections as references."Alexey Bataev2018-03-013-50/+11
| | | | | | | This reverts commit r326328 to remove checks for emission of certain sections after discussion with Eric Christofer. llvm-svn: 326436
OpenPOWER on IntegriCloud