summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [SelectionDAG] Transfer DbgValues when integer operations are promotedAaron Smith2018-03-191-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: DbgValue nodes were not transferred when integer DAG nodes were promoted. For example, if an i32 add node was promoted to an i64 add node by DAGTypeLegalizer::PromoteIntegerResult(), its DbgValue node was not transferred to the new node. The simple fix is to update SetPromotedInteger() to transfer DbgValues. Add AArch64/dbg-value-i8.ll to test this change and fix ARM/debug-info-d16-reg.ll which had the wrong DILocalVariable nodes with arg numbers even though they are not for function parameters. Patch by Se Jong Oh! Reviewers: vsk, JDevlieghere, aprantl Reviewed By: JDevlieghere Subscribers: javed.absar, kristof.beyls, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44546 llvm-svn: 327919
* [DAGCombiner] Fix type in comment. NFCCraig Topper2018-03-191-1/+1
| | | | llvm-svn: 327916
* [DAG, X86] Revert r327197 "Revert r327170, r327171, r327172"Nirav Dave2018-03-191-227/+152
| | | | | | | Reland ISel cycle checking improvements after simplifying node id invariant traversal and correcting typo. llvm-svn: 327898
* Revert [MachineLICM] This reverts commit rL327856Zaara Syeda2018-03-192-103/+1
| | | | | | Failing build bots. Revert the commit now. llvm-svn: 327864
* [CodeGen] Avoid handling DBG_VALUE in the LivePhysRegs ↵Matt Davis2018-03-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | (addUses,removeDefs,stepForward) Summary: This patch prevents DBG_VALUE instructions from influencing LivePhysRegs::stepBackwards and stepForwards. In at least one case, specifically branch folding, the stepBackwards logic was having an influence on code generation. The result was that certain code compiled with '-g -O2' would differ from that compiled with '-O2' alone. It seems that the original logic, accounting for DBG_VALUE, was influencing the placement of an IMPLICIT_DEF which had a later impact on how blocks were processed in branch folding. Reviewers: kparzysz, MatzeB Reviewed By: kparzysz Subscribers: bjope, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D43850 llvm-svn: 327862
* [MachineLICM] Add functions to MachineLICM to hoist invariant storesZaara Syeda2018-03-192-1/+103
| | | | | | | | | | | | | | | | This patch adds functions to allow MachineLICM to hoist invariant stores. Currently, MachineLICM does not hoist any store instructions, however when storing the same value to a constant spot on the stack, the store instruction should be considered invariant and be hoisted. The function isInvariantStore iterates each operand of the store instruction and checks that each register operand satisfies isCallerPreservedPhysReg. The store may be fed by a copy, which is hoisted by isCopyFeedingInvariantStore. This patch also adds the PowerPC changes needed to consider the stack register as caller preserved. Differential Revision: https://reviews.llvm.org/D40196 llvm-svn: 327856
* [MergeICmps] Re-land 324317 "Enable the MergeICmps Pass by default."Clement Courbet2018-03-191-5/+4
| | | | | | Now that PR36557 is fixed. llvm-svn: 327840
* Stylish change. NFCXin Tong2018-03-191-2/+2
| | | | llvm-svn: 327838
* [dsymutil] Rename llvm-dsymutil -> dsymutilJonas Devlieghere2018-03-181-1/+1
| | | | | | | | | | | Now that almost all functionality of Apple's dsymutil has been upstreamed, the open source variant can be used as a drop in replacement. Hence we feel it's no longer necessary to have the llvm prefix. Differential revision: https://reviews.llvm.org/D44527 llvm-svn: 327790
* Revert "[DAG, X86] Revert r327197 "Revert r327170, r327171, r327172""Nirav Dave2018-03-171-152/+227
| | | | | | as it times out building test-suite on PPC. llvm-svn: 327778
* [DAG, X86] Revert r327197 "Revert r327170, r327171, r327172"Nirav Dave2018-03-171-227/+152
| | | | | | | Reland ISel cycle checking improvements after simplifying and reducing node id invariant traversal. llvm-svn: 327777
* [X86] Added support for nocf_check attribute for indirect Branch TrackingOren Ben Simhon2018-03-171-1/+2
| | | | | | | | | | | | | | | X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
* [SelectionDAG] Handle big endian target BITCAST in computeKnownBits()Jonas Paulsson2018-03-171-6/+5
| | | | | | | | | | | | | | | The BITCAST handling in computeKnownBits() previously only worked for little endian. This patch reverses the iteration over elements for a big endian target which allows this to work in this case also. SystemZ test case. Review: Eli Friedman https://reviews.llvm.org/D44249 llvm-svn: 327764
* Quiet unused variable warnings. NFC.David L Kreitzer2018-03-161-0/+3
| | | | | | Differential revision: https://reviews.llvm.org/D44583 llvm-svn: 327745
* Revert r327721 "This patch fixes the invalid usage of OptSize in Machine ↵Reid Kleckner2018-03-161-3/+3
| | | | | | | | | Combiner." It causes asserts when compiling Chromium on Win32 with optimizations. We compile many things with -Os. llvm-svn: 327733
* This patch fixes the invalid usage of OptSize in Machine Combiner.Andrew V. Tischenko2018-03-161-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D43813 llvm-svn: 327721
* [SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job ↵Craig Topper2018-03-151-6/+15
| | | | | | | | | | | | | | | | picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
* [WebAssembly] Add DebugLoc information to WebAssembly block and loop.Derek Schuff2018-03-151-0/+10
| | | | | | | Patch by Yury Delendik Differential Revision: https://reviews.llvm.org/D44448 llvm-svn: 327673
* Re-land r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols ↵Reid Kleckner2018-03-152-7/+178
| | | | | | | | | for lexical scopes" This is safe to land now that we don't copy FunctionInfo when rehashing the DenseMap. llvm-svn: 327670
* [codeview] Fix sense of the assertion about hashtable insertionReid Kleckner2018-03-151-1/+1
| | | | llvm-svn: 327669
* [codeview] Delete FunctionInfo copy ctor and move out of DenseMapReid Kleckner2018-03-152-5/+11
| | | | | | | | | | | | | We were unnecessarily copying a bunch of these FunctionInfo objects around when rehashing the DenseMap. Furthermore, r327620 introduced pointers referring to objects owned by FunctionInfo, and the default copy ctor did the wrong thing in this case, leading to use-after-free when the DenseMap gets rehashed. I will rebase r327620 on this next and recommit it. llvm-svn: 327665
* Revert r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols ↵Reid Kleckner2018-03-152-175/+7
| | | | | | | | | | for lexical scopes" It is causing crashes when compiling Chrome in debug mode. I'll try to debug it in a second. llvm-svn: 327657
* [CodeView] Initial support for emitting S_BLOCK32 symbols for lexical scopesBrock Wyma2018-03-152-7/+175
| | | | | | | | | This patch sorts local variables by lexical scope and emits them inside an appropriate S_BLOCK32 CodeView symbol. Differential Revision: https://reviews.llvm.org/D42926 llvm-svn: 327620
* [FastISel] Sink local value materializations to first useReid Kleckner2018-03-143-3/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
* [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
OpenPOWER on IntegriCloud