summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] Use MIR syntax for MachineMemOperand printingFrancis Visoiu Mistrih2018-03-144-271/+211
| | | | | | | | | | Get rid of the "; mem:" suffix and use the one we use in MIR: ":: (load 2)". rdar://38163529 Differential Revision: https://reviews.llvm.org/D42377 llvm-svn: 327580
* [AArch64] Keep track of MIFlags in the LoadStoreOptimizerFrancis Visoiu Mistrih2018-03-141-0/+6
| | | | | | | | | | | | | | | | Merging: * $x26, $x25 = frame-setup LDPXi $sp, 0 * $sp = frame-destroy ADDXri $sp, 64, 0 into an LDPXpost should preserve the flags from both instructions as following: * frame-setup frame-destroy LDPXpost Differential Revision: https://reviews.llvm.org/D44446 llvm-svn: 327533
* [X86] Teach X86TargetLowering::targetShrinkDemandedConstant to set ↵Craig Topper2018-03-141-2/+16
| | | | | | | | | | | | non-demanded bits if it helps created an and mask that can be matched as a zero extend. I had to modify the bswap recognition to allow unshrunk masks to make this work. Fixes PR36689. Differential Revision: https://reviews.llvm.org/D44442 llvm-svn: 327530
* SjLjEHPrepare: Don't reg-to-mem swifterror valuesArnold Schwaighofer2018-03-141-22/+7
| | | | | | | | | | | | | | | | | swifterror llvm values model the swifterror register as memory at the LLVM IR level. ISel will perform adhoc mem-to-reg on them. swifterror values are constraint in how they can be used. Spilling them to memory is not allowed. SjLjEHPrepare tried to lower swifterror values to memory which is unecessary since the back-end will spill and reload the register as neccessary (as long as clobbering calls are marked as such which is the case here) and further leads to invalid IR because swifterror values can't be stored to memory. rdar://38164004 llvm-svn: 327521
* [CodeGen] allow printing of zero latency in sched commentsSanjay Patel2018-03-141-5/+3
| | | | | | | | | | I don't know how to expose this in a test. There are ARM / AArch64 sched classes that include zero latency instructions, but I'm not seeing sched info printed for those targets. X86 will almost certainly have these soon (see PR36671), but no model has 'let Latency = 0' currently. llvm-svn: 327518
* Fix msvc compiler error in r327498Pavel Labath2018-03-141-1/+1
| | | | | | | msvc reports an "illegal indirection" error here. Attempt to appease it with a different initialization syntax. llvm-svn: 327500
* Explicitly initialize dwarf::FormParams in DIEInteger::SizeOfPavel Labath2018-03-141-1/+1
| | | | | | | | | | | | | | | | | This could end up inititialized if someone called the function with a null AsmPrinter. Right now this only happens in DIEHash unit tests, presumably because it was hard to create an AsmPrinter in the context of unit tests. This only worked before r327486 because those tests did not use any dwarf forms whose size actually depended on the dwarf version (otherwise, they would have crashed due to null dereference). I fix the uninitialized error, by explicitly initializing FormParams to an invalid value, which will cause getFixedFormByteSize to return None if called with a form with version-dependent size. A more principled solution might be to fix the DIEHash tests to always pass in a valid AsmPrinter. llvm-svn: 327498
* DWARF: Unify form size handling codePavel Labath2018-03-141-46/+8
| | | | | | | | | | | | | | | | | Summary: This patch replaces the two switches which are deducing the size of various forms with a single implementation. I have put the new implementation into BinaryFormat, to avoid introducing dependencies between the two independent libraries (DebugInfo and CodeGen) that need this functionality. Reviewers: aprantl, JDevlieghere, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44418 llvm-svn: 327486
* 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
OpenPOWER on IntegriCloud