summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [DAG] Fix node id invalidation in Instruction Selection.Nirav Dave2018-03-231-3/+3
| | | | | | Invalidation should be bit negation. Add missing negation. llvm-svn: 328287
* [DAGCombiner] Fold (zext (and/or/xor (shl/shr (load x), cst), cst))Guozhi Wei2018-03-221-0/+80
| | | | | | | | | | | | | | In our real world application, we found the following optimization is missed in DAGCombiner (zext (and/or/xor (shl/shr (load x), cst), cst)) -> (and/or/xor (shl/shr (zextload x), (zext cst)), (zext cst)) If the user of original zext is an add, it may enable further lea optimization on x86. This patch add a new function CombineZExtLogicopShiftLoad to do this optimization. Differential Revision: https://reviews.llvm.org/D44402 llvm-svn: 328252
* [MachineOutliner][NFC] Refactoring + comments in runOnModuleJessica Paquette2018-03-221-12/+33
| | | | | | | | | | | Split up some of the if/else branches in runOnModule. Elaborate on some comments. Replace a call to getOrCreateMachineFunction with getMachineFunction. This makes it clearer what's happening in runOnModule, and ensures that the outliner doesn't create any MachineFunctions which will never be used by the outliner (or anything else, really). llvm-svn: 328240
* [CodeGen] Add a new pass for PostRA sinkJun Bum Lim2018-03-224-1/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This pass sinks COPY instructions into a successor block, if the COPY is not used in the current block and the COPY is live-in to a single successor (i.e., doesn't require the COPY to be duplicated). This avoids executing the the copy on paths where their results aren't needed. This also exposes additional opportunites for dead copy elimination and shrink wrapping. These copies were either not handled by or are inserted after the MachineSink pass. As an example of the former case, the MachineSink pass cannot sink COPY instructions with allocatable source registers; for AArch64 these type of copy instructions are frequently used to move function parameters (PhyReg) into virtual registers in the entry block.. For the machine IR below, this pass will sink %w19 in the entry into its successor (%bb.1) because %w19 is only live-in in %bb.1. ``` %bb.0: %wzr = SUBSWri %w1, 1 %w19 = COPY %w0 Bcc 11, %bb.2 %bb.1: Live Ins: %w19 BL @fun %w0 = ADDWrr %w0, %w19 RET %w0 %bb.2: %w0 = COPY %wzr RET %w0 ``` As we sink %w19 (CSR in AArch64) into %bb.1, the shrink-wrapping pass will be able to see %bb.0 as a candidate. With this change I observed 12% more shrink-wrapping candidate and 13% more dead copies deleted in spec2000/2006/2017 on AArch64. Reviewers: qcolombet, MatzeB, thegameg, mcrosier, gberry, hfinkel, john.brawn, twoh, RKSimon, sebpop, kparzysz Reviewed By: sebpop Subscribers: evandro, sebpop, sfertile, aemerson, mgorny, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D41463 llvm-svn: 328237
* [DAG, X86] Fix ISel-time node insertion idsNirav Dave2018-03-221-2/+17
| | | | | | | | | | | | | | | | As in SystemZ backend, correctly propagate node ids when inserting new unselected nodes into the DAG during instruction Seleciton for X86 target. Fixes PR36865. Reviewers: jyknight, craig.topper Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D44797 llvm-svn: 328233
* [GISel]: Fix incorrect IRTranslation while translating null pointer typesAditya Nandakumar2018-03-221-3/+9
| | | | | | | | | | | | | | | https://reviews.llvm.org/D44762 Currently IRTranslator produces %vreg17<def>(p0) = G_CONSTANT 0; instead we should build %vreg16(s64) = G_CONSTANT 0 %vreg17(p0) = G_INTTOPTR %vreg16 reviewed by @aemerson. llvm-svn: 328218
* [DWARF] Add EmitDwarfOffset function, NFC.Alexey Bataev2018-03-221-0/+4
| | | | | | Added EmitDwarfOffset function after discussion with Eric Christofer. llvm-svn: 328212
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-215-5/+5
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* Sink Analysis/ObjectUtil(canBeOmittedFromSymbolTable) into IR so it can be ↵David Blaikie2018-03-211-2/+1
| | | | | | legitimately be used by Object/IRSymtab llvm-svn: 328135
* [Hexagon] Eliminate subregisters from PHI nodes before pipeliningKrzysztof Parzyszek2018-03-211-39/+74
| | | | | | | | | | | | | | | | The pipeliner needs to remove instructions from the SlotIndexes structure when they are deleted. Otherwise, the SlotIndexes map has stale data, and an assert will occur when adding new instructions. This patch also changes the pipeliner to make the back-edge of a loop carried dependence 1 cycle. The 1 cycle latency is added to the anti-dependence that represents the back-edge. This changes eliminates a couple of hacks added to the pipeliner to handle the latency of the back-edge. It is needed to correctly pipeline the test case for the sub-register elimination pass. llvm-svn: 328113
* [SelectionDAG] Support multiple dangling debug info for one valueBjorn Pettersson2018-03-212-50/+50
| | | | | | | | | | | | | | | | | | | | | Summary: When building the selection DAG we sometimes need to postpone the handling of a dbg.value until the value it should refer to is created. This is done by using the DanglingDebugInfoMap. In the past this map has been limited to hold one dangling dbg.value per value. This patch removes that restriction. Reviewers: aprantl, rnk, probinson, vsk Reviewed By: aprantl Subscribers: Ka-Ka, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44610 llvm-svn: 328084
* [ReachingDefAnalysis] Fix what I assume to be a typo ↵Craig Topper2018-03-201-4/+4
| | | | | | | | ReachingDedDefaultVal->ReachingDefDefaultVal. Unless Ded has some many I don't know about. llvm-svn: 328043
* [DEBUGINFO] Add -no-dwarf-debug-ranges option.Alexey Bataev2018-03-203-4/+27
| | | | | | | | | | | | | | Summary: Added option -no-dwarf-debug-ranges option to disable emission of .debug_ranges section. Reviewers: probinson, echristo Subscribers: aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D44384 llvm-svn: 328030
* [PowerPC][LegalizeFloatTypes] Move the PPC hacks for (i32 ↵Craig Topper2018-03-201-37/+0
| | | | | | | | | | | | | | fp_to_sint/fp_to_uint (ppcf128 X)) out of LegalizeFloatTypes and into PPC specific code I'm not entirely sure these hacks are still needed. If you remove the hacks completely, the name of the library call that gets generated doesn't match the grep the test previously had. So the test wasn't really checking anything. If the hack is still needed it belongs in PPC specific code. I believe the FP_TO_SINT code here is the only place in the tree where a FP_ROUND_INREG node is created today. And I don't think its even being used correctly because the legalization returned a BUILD_PAIR with the same value twice. That doesn't seem right to me. By moving the code entirely to PPC we can avoid creating the FP_ROUND_INREG at all. I replaced the grep in the existing test with full checks generated by hacking update_llc_test_check.py to support ppc32 just long enough to generate it. Differential Revision: https://reviews.llvm.org/D44061 llvm-svn: 328017
* [XRay] Lazily compute MachineLoopInfo instead of requiring it.Michael Zolotukhin2018-03-201-3/+17
| | | | | | | | | | | | | | | | Summary: Currently X-Ray Instrumentation pass has a dependency on MachineLoopInfo (and thus on MachineDominatorTree as well) and we have to compute them even if X-Ray is not used. This patch changes it to a lazy computation to save compile time by avoiding these redundant computations. Reviewers: dberris, kubamracek Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D44666 llvm-svn: 327999
* [DEBUGINFO] Add flag -no-dwarf-pub-sections to disable pub sections.Alexey Bataev2018-03-203-1/+15
| | | | | | | | | | | | | | Summary: Added a flag -no-dwarf-pub-sections, which allows to disable emission of DWARF public sections. Reviewers: probinson, echristo Subscribers: aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D44385 llvm-svn: 327994
* [CGP] Avoid segmentation fault when doing PHI node simplificationsBjorn Pettersson2018-03-201-61/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Made PHI node simplifiations more robust in several ways: - Minor refactoring to let the SimplificationTracker own the sets with new PHI/Select nodes that are introduced. This is maybe not mapping to the original intention with the SimplificationTracker, but IMHO it encapsulates the logic behind those sets a little bit better. - MatchPhiNode can sometimes populate the Matched set with several entries, where it maps one PHI node to different candidates for replacement. The Matched set is changed into a SmallSetVector to make sure we get a deterministic iteration when doing the replacements. - As described above we may get several different replacements for a single PHI node. The loop in MatchPhiSet that is doing the replacements could end up calling eraseFromParent several times for the same PHI node, resulting in segmentation faults. This problem was supposed to be fixed in rL327250, but due to the non-determinism(?) it only appeared to be fixed (I still got crashes sometime when turning on/off -print-after-all etc to get different iteration order in the DenseSets). With this patch we follow the deterministic ordering in the Matched set when replacing the PHI nodes. If we find a new replacement for an already replaced PHI node we replace the new replacement by the old replacement instead. This is quite similar to what happened in the rl327250 patch, but here we also recursively verify that the old replacement hasn't been replaced already. - It was really hard to track down the fault described above (segementation fault due to doing eraseFromParent multiple times for the same instruction). The fault was intermittent and small changes in the code, or simply turning on -print-after-all etc could make the problem go away. This was basically due to the iteration over PhiNodesToMatch in MatchPhiSet no being deterministic. Therefore I've changed the data structure for the SimplificationTracker::AllPhiNodes into an SmallSetVector. This gives a deterministic behavior. Reviewers: skatkov, john.brawn Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44571 llvm-svn: 327961
* [ShrinkWrap] Take into account landing padQuentin Colombet2018-03-201-0/+16
| | | | | | | | | | | | | When scanning the function for CSRs uses and defs, also check if the basic block are landing pads. Consider that landing pads needs the CSRs to be properly set. That way we force the prologue/epilogue to always be pushed out of the problematic "throw" region. The "throw" region is problematic because the jumps are not properly modeled. Fixes PR36513 llvm-svn: 327942
* [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
OpenPOWER on IntegriCloud