summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/PrologEpilogInserter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Merge memtag instructions with adjacent stack slots."Evgenii Stepanov2020-01-081-4/+0
| | | | | | | | | | | | *** Bad machine code: Tied use must be a register *** - function: stg_alloca17 - basic block: %bb.0 entry (0x20076710580) - instruction: early-clobber %0:gpr64common, early-clobber %1:gpr64sp = STGloop 272, %stack.0.a :: (store 272 into %ir.a, align 16) - operand 3: %stack.0.a http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/21481/steps/test-check-all/logs/stdio This reverts commit b675a7628ce6a21b1e4a71c079a67badfb8b073d.
* Merge memtag instructions with adjacent stack slots.Evgenii Stepanov2020-01-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Detect a run of memory tagging instructions for adjacent stack frame slots, and replace them with a shorter instruction sequence * replace STG + STG with ST2G * replace STGloop + STGloop with STGloop This code needs to run when stack slot offsets are already known, but before FrameIndex operands in STG instructions are eliminated; that's the reason for the new hook in PrologueEpilogue. This change modifies STGloop and STZGloop pseudos to take the size as an immediate integer operand, and base address as a FI operand when possible. This is needed to simplify recognizing an STGloop instruction as operating on a stack slot post-regalloc. This improves memtag code size by ~0.25%, and it looks like an additional ~0.1% is possible by rearranging the stack frame such that consecutive STG instructions reference adjacent slots (patch pending). Reviewers: pcc, ostannard Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70286
* Sink all InitializePasses.h includesReid Kleckner2019-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* [LLVM][Alignment] Introduce Alignment In MachineFrameInfoGuillaume Chatelet2019-08-211-1/+1
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65800 llvm-svn: 369531
* [PEI] Don't re-allocate a pre-allocated stack protector slotFrancis Visoiu Mistrih2019-07-171-2/+19
| | | | | | | | | | | | | | | | | | | | | | The LocalStackSlotPass pre-allocates a stack protector and makes sure that it comes before the local variables on the stack. We need to make sure that later during PEI we don't re-allocate a new stack protector slot. If that happens, the new stack protector slot will end up being **after** the local variables that it should be protecting. Therefore, we would have two slots assigned for two different stack protectors, one at the top of the stack, and one at the bottom. Since PEI will overwrite the assigned slot for the stack protector, the load that is used to compare the value of the stack protector will use the slot assigned by PEI, which is wrong. For this, we need to check if the object is pre-allocated, and re-use that pre-allocated slot. Differential Revision: https://reviews.llvm.org/D64757 llvm-svn: 366371
* [CodeGen][NFC] Simplify checks for stack protector index checkingFrancis Visoiu Mistrih2019-07-171-9/+7
| | | | | | | Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex() >= 0`. llvm-svn: 366369
* [DebugInfo] Avoid adding too much indirection to pointer-valued variablesJeremy Morse2019-07-011-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch addresses PR41675, where a stack-pointer variable is dereferenced too many times by its location expression, presenting a value on the stack as the pointer to the stack. The difference between a stack *pointer* DBG_VALUE and one that refers to a value on the stack, is currently the indirect flag. However the DWARF backend will also try to guess whether something is a memory location or not, based on whether there is any computation in the location expression. By simply prepending the stack offset to existing expressions, we can accidentally convert a register location into a memory location, which introduces a suprise (and unintended) dereference. The solution is to add DW_OP_stack_value whenever we add a DIExpression computation to a stack *pointer*. It's an implicit location computed on the expression stack, thus needs to be flagged as a stack_value. For the edge case where the offset is zero and the location could be a register location, DIExpression::prepend will still generate opcodes, and thus DW_OP_stack_value must still be added. Differential Revision: https://reviews.llvm.org/D63429 llvm-svn: 364736
* PEI: Add default handling of spills to registersMatt Arsenault2019-06-261-9/+22
| | | | llvm-svn: 364472
* Describe stack-id as an enumSander de Smalen2019-06-171-8/+14
| | | | | | | | | | | | | | | | | This patch changes MIR stack-id from an integer to an enum, and adds printing/parsing support for this in MIR files. The default stack-id '0' is now renamed to 'default'. This should make MIR tests that have stack objects with different stack-ids more descriptive. It also clarifies code operating on StackID. Reviewers: arsenm, thegameg, qcolombet Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D60137 llvm-svn: 363533
* [DebugInfoMetadata] Refactor DIExpression::prepend constants (NFC)Petar Jovanovic2019-05-201-2/+4
| | | | | | | | | | | Refactor DIExpression::With* into a flag enum in order to be less error-prone to use (as discussed on D60866). Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D61943 llvm-svn: 361137
* [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.Markus Lavin2019-04-301-3/+17
| | | | | | | | | | | | | | | | | | | | The PrologEpilogInserter need to insert a DW_OP_deref_size before prepending a memory location expression to an already implicit expression to avoid having the existing expression act on the memory address instead of the value behind it. The reason for using DW_OP_deref_size and not plain DW_OP_deref is that big-endian targets need to read the right size as simply truncating a larger read would yield the wrong result (LSB bytes are not at the lower address). This re-commit fixes issues reported in the first one. Namely deref was inserted under wrong conditions and additionally the deref_size argument was incorrectly encoded. Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 359535
* Revert r358268 "[DebugInfo] DW_OP_deref_size in PrologEpilogInserter."Hans Wennborg2019-04-121-13/+3
| | | | | | | | | | | | | | | | | | | It causes clang to crash while building Chromium. See https://crbug.com/952230 for reproducer. > The PrologEpilogInserter need to insert a DW_OP_deref_size before > prepending a memory location expression to an already implicit > expression to avoid having the existing expression act on the memory > address instead of the value behind it. > > The reason for using DW_OP_deref_size and not plain DW_OP_deref is that > big-endian targets need to read the right size as simply truncating a > larger read would yield the wrong result (LSB bytes are not at the lower > address). > > Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 358281
* [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.Markus Lavin2019-04-121-3/+13
| | | | | | | | | | | | | | | | The PrologEpilogInserter need to insert a DW_OP_deref_size before prepending a memory location expression to an already implicit expression to avoid having the existing expression act on the memory address instead of the value behind it. The reason for using DW_OP_deref_size and not plain DW_OP_deref is that big-endian targets need to read the right size as simply truncating a larger read would yield the wrong result (LSB bytes are not at the lower address). Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 358268
* Enforce StackID definition in PEISander de Smalen2019-04-021-2/+25
| | | | | | | | | | | | | | | There are various places in LLVM where the definition of StackID is not properly honoured, for example in PEI where objects with a StackID > 0 are allocated on the default stack (StackID0). This patch enforces that PEI only considers allocating objects to StackID 0. Reviewers: arsenm, thegameg, MatzeB Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D60062 llvm-svn: 357460
* PEI: Delay checking requiresFrameIndexReplacementScavengingMatt Arsenault2019-03-271-4/+10
| | | | | | | | | | Currently this is called before the frame size is set on the function. For AMDGPU, the scavenger is used for large frames where part of the offset needs to be materialized in a register, so estimating the frame size is useful for knowing whether the scavenger is useful. llvm-svn: 357087
* [DebugInfo] Keep parameter DBG_VALUEs before prologue codeDavid Stenberg2019-02-121-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory change for removing the code from DebugHandlerBase::beginFunction() which changes the starting label for the first non-overlapping DBG_VALUEs of parameters to the beginning of the function. It does that to be able to show parameters when entering a function. However, that code does not consider what defines the values, which can result in the ranges for the debug values starting before their defining instructions. That code is removed in a follow-up patch. When prologue code is inserted, it leads to DBG_VALUEs that start directly in the entry block being moved down after the prologue instructions. This patch fixes that by stashing away DBG_VALUEs for parameters before emitting the prologue, and then reinserts them at the start of the block. This assumes that there is no target that somehow clobbers parameter registers in the frame setup; there is no such case in the lit tests at least. See PR40188 for more information. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: bjope, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D57510 llvm-svn: 353823
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [CodeGen] Take SPAdj into account for STATEPOINT liveness argsThan McIntosh2018-11-261-1/+1
| | | | | | | | | | | | | | | | | | Summary: STATEPOINT records its args' locations on stack relative to SP. If the SP is changed, take that into account. This patch authored by Cherry Zhang <cherryyz@google.com>. Reviewers: thanm, reames Reviewed By: reames Subscribers: reames, llvm-commits Differential Revision: https://reviews.llvm.org/D53603 llvm-svn: 347569
* [Power9] Allow gpr callee saved spills in prologue to vectors registersZaara Syeda2018-11-091-0/+28
| | | | | | | | | | | | | | Currently in llvm, CalleeSavedInfo can only assign a callee saved register to stack frame index to be spilled in the prologue. We would like to enable spilling gprs to vector registers. This patch adds the capability to spill to other registers aside from just the stack. It also adds the changes for power9 to spill gprs to volatile vector registers when they are available. This happens only for leaf functions when using the option -ppc-enable-pe-vector-spills. Differential Revision: https://reviews.llvm.org/D39386 llvm-svn: 346512
* CodeGen: Remove pipeline dependencies on StackProtector; NFCMatthias Braun2018-07-131-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This re-applies r336929 with a fix to accomodate for the Mips target scheduling multiple SelectionDAG instances into the pass pipeline. PrologEpilogInserter and StackColoring depend on the StackProtector analysis being alive from the point it is run until PEI, which requires that they are all scheduled in the same FunctionPassManager. Inserting a (machine) ModulePass between StackProtector and PEI results in these passes being in separate FunctionPassManagers and the StackProtector is not available for PEI. PEI and StackColoring don't use much information from the StackProtector pass, so transfering the required information to MachineFrameInfo is cleaner than keeping the StackProtector pass around. This commit moves the SSP layout information to MFI instead of keeping it in the pass. This patch set (D37580, D37581, D37582, D37583, D37584, D37585, D37586, D37587) is a first draft of the pagerando implementation described in http://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html. Patch by Stephen Crane <sjc@immunant.com> Differential Revision: https://reviews.llvm.org/D49256 llvm-svn: 336964
* Revert "(HEAD -> master, origin/master, arcpatch-D37582) CodeGen: Remove ↵Matthias Braun2018-07-121-5/+9
| | | | | | | | | | pipeline dependencies on StackProtector; NFC" This was triggering pass scheduling failures. This reverts commit r336929. llvm-svn: 336934
* CodeGen: Remove pipeline dependencies on StackProtector; NFCMatthias Braun2018-07-121-9/+5
| | | | | | | | | | | | | | | | | | | | | | | PrologEpilogInserter and StackColoring depend on the StackProtector analysis being alive from the point it is run until PEI, which requires that they are all scheduled in the same FunctionPassManager. Inserting a (machine) ModulePass between StackProtector and PEI results in these passes being in separate FunctionPassManagers and the StackProtector is not available for PEI. PEI and StackColoring don't use much information from the StackProtector pass, so transfering the required information to MachineFrameInfo is cleaner than keeping the StackProtector pass around. This commit moves the SSP layout information to MFI instead of keeping it in the pass. This patch set (D37580, D37581, D37582, D37583, D37584, D37585, D37586, D37587) is a first draft of the pagerando implementation described in http://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html. Patch by Stephen Crane <sjc@immunant.com> Differential Revision: https://reviews.llvm.org/D49256 llvm-svn: 336929
* [DebugInfo] Make sure all DBG_VALUEs' reguse operands have IsDebug propertyMikael Holmen2018-06-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: In some cases, these operands lacked the IsDebug property, which is meant to signal that they should not affect codegen. This patch adds a check for this property in the MachineVerifier and adds it where it was missing. This includes refactorings to use MachineInstrBuilder construction functions instead of manually setting up the intrinsic everywhere. Patch by: JesperAntonsson Reviewers: aprantl, rnk, echristo, javed.absar Reviewed By: aprantl Subscribers: qcolombet, sdardis, nemanjai, JDevlieghere, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D48319 llvm-svn: 335214
* Use MF instead of Fn for MachineFunction references. NFCFrancis Visoiu Mistrih2018-06-051-97/+97
| | | | llvm-svn: 333973
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-11/+13
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [PEI][NFC] Move StackSize opt-remark code next to -warn-stack codeFrancis Visoiu Mistrih2018-02-051-7/+6
| | | | | | | This allows us to make sure we're always having the same sizes in both remarks and warnings. llvm-svn: 324283
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-151-8/+8
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-3/+3
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-081-2/+2
| | | | | | | | This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
* Move TargetFrameLowering.h to CodeGen where it's implementedDavid Blaikie2017-11-031-1/+1
| | | | | | | | | | | This header already includes a CodeGen header and is implemented in lib/CodeGen, so move the header there to match. This fixes a link error with modular codegeneration builds - where a header and its implementation are circularly dependent and so need to be in the same library, not split between two like this. llvm-svn: 317379
* [PEI] Simplify handling of targets with no phys regs. NFCFrancis Visoiu Mistrih2017-11-031-13/+3
| | | | | | | | | Make doSpillCalleeSavedRegs a member function, instead of passing most of the members of PEI as arguments. Differential Review: https://reviews.llvm.org/D35642 llvm-svn: 317309
* [NFC] Convert OptimizationRemarkEmitter old emit() calls to new closureVivek Pandya2017-10-111-5/+6
| | | | | | | | | | | | | | parameterized emit() calls Summary: This is not functional change to adopt new emit() API added in r313691. Reviewed By: anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38285 llvm-svn: 315476
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-10-101-17/+38
| | | | | | other minor fixes (NFC). llvm-svn: 315380
* [PEI] Remove required properties and use 'if' instead of std::functionReid Kleckner2017-10-061-49/+23
| | | | | | | | | | | | | | | | | | Summary: After r303360, we initialize UsesCalleeSaves in runOnMachineFunction, which runs after getRequiredProperties. UsesCalleeSaves was initialized to 'false', so getRequiredProperties would always return an empty set. We don't have a TargetMachine available early anymore after r303360. Just removing the requirement of NoVRegs seems to make things work, so let's do that. Reviewers: thegameg, dschuff, MatzeB Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D38597 llvm-svn: 315089
* [CodeGen] Emit necessary .note sections for -fsplit-stackThan McIntosh2017-09-271-1/+5
| | | | | | | | | | | | | | | | | | | | | Summary: According to https://gcc.gnu.org/wiki/SplitStacks, the linker expects a zero-sized .note.GNU-split-stack section if split-stack is used (and also .note.GNU-no-split-stack section if it also contains non-split-stack functions), so it can handle the cases where a split-stack function calls non-split-stack function. This change adds the sections if needed. Fixes PR #34670. Reviewers: thanm, rnk, luqmana Reviewed By: rnk Subscribers: llvm-commits Patch by Cherry Zhang <cherryyz@google.com> Differential Revision: https://reviews.llvm.org/D38051 llvm-svn: 314335
* Retire the llvm.dbg.mir hack after r311594.Adrian Prantl2017-08-231-3/+0
| | | | llvm-svn: 311610
* Add "Restored" flag to CalleeSavedInfoKrzysztof Parzyszek2017-08-101-2/+2
| | | | | | | | | | | The liveness-tracking code assumes that the registers that were saved in the function's prolog are live outside of the function. Specifically, that registers that were saved are also live-on-exit from the function. This isn't always the case as illustrated by the LR register on ARM. Differential Revision: https://reviews.llvm.org/D36160 llvm-svn: 310619
* Remove PrologEpilogInserter's usage of DBG_VALUE's offset fieldAdrian Prantl2017-08-011-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the last half-dozen commits to LLVM I removed code that became dead after removing the offset parameter from llvm.dbg.value gradually proceeding from IR towards the backend. Before I can move on to DwarfDebug and friends there is one last side-called offset I need to remove: This patch modifies PrologEpilogInserter's use of the DBG_VALUE's offset argument to use a DIExpression instead. Because the PrologEpilogInserter runs at the Machine level I had to play a little trick with a named llvm.dbg.mir node to get the DIExpressions to print in MIR dumps (which print the llvm::Module followed by the MachineFunction dump). I also had to add rudimentary DwarfExpression support to CodeView and as a side-effect also fixed a bug (CodeViewDebug::collectVariableInfo was supposed to give up on variables with complex DIExpressions, but would fail to do so for fragments, which are also modeled as DIExpressions). With this last holdover removed we will have only one canonical way of representing offsets to debug locations which will simplify the code in DwarfDebug (and future versions of CodeViewDebug once it starts handling more complex expressions) and make it easier to reason about. This patch is NFC-ish: All test case changes are for assembler comments and the binary output does not change. rdar://problem/33580047 Differential Revision: https://reviews.llvm.org/D36125 llvm-svn: 309751
* [OptRemark] Allow streaming of 64-bit integersAdam Nemet2017-07-271-1/+1
| | | | llvm-svn: 309293
* [PEI] Fix refactoring from r308664Francis Visoiu Mistrih2017-07-201-1/+1
| | | | llvm-svn: 308666
* [PEI] Separate saving and restoring CSRs into different functions. NFCFrancis Visoiu Mistrih2017-07-201-66/+51
| | | | | | | | | | | Split insertCSRSpillsAndRestores into insertCSRSaves + insertCSRRestores. This is mostly useful for future shrink-wrapping improvements where we want to save / restore a specific part of the CSRs in a specific block. Differential Revision: https://reviews.llvm.org/D35644 llvm-svn: 308664
* Revert "[PEI] Simplify handling of targets with no phys regs. NFC"Francis Visoiu Mistrih2017-07-201-8/+23
| | | | | | | | This reverts commit ce30ab6e5598f3c24f59ad016dc9526bc9a1d450. sanitizer-ppc64le-linux seems to segfault when testing the sanitizers. llvm-svn: 308581
* Revert "[PEI] Separate saving and restoring CSRs into different functions. NFC"Francis Visoiu Mistrih2017-07-201-51/+66
| | | | | | | | This reverts commit 540f6a26ae932469804a379ce9a8cbe715d59c23. sanitizer-ppc64le-linux seems to segfault when testing the sanitizers. llvm-svn: 308580
* [PEI] Separate saving and restoring CSRs into different functions. NFCFrancis Visoiu Mistrih2017-07-201-66/+51
| | | | | | | | | | | Split insertCSRSpillsAndRestores into insertCSRSaves + insertCSRRestores. This is mostly useful for future shrink-wrapping improvements where we want to save / restore a specific part of the CSRs in a specific block. Differential Revision: https://reviews.llvm.org/D35644 llvm-svn: 308573
* Revert "[PEI] Separate saving and restoring CSRs into different functions. NFC"Francis Visoiu Mistrih2017-07-201-51/+66
| | | | | | This reverts commit a84d1fa6847e70ebf63594d41a00b473c941bd72. llvm-svn: 308562
* [PEI] Add basic opt-remarks supportFrancis Visoiu Mistrih2017-07-191-0/+13
| | | | | | | | | | Add optimization remarks support to the PrologueEpilogueInserter. For now, emit the stack size as an analysis remark, but more additions wrt shrink-wrapping may be added. https://reviews.llvm.org/D35645 llvm-svn: 308556
* [PEI] Simplify handling of targets with no phys regs. NFCFrancis Visoiu Mistrih2017-07-191-23/+8
| | | | | | | | | Make doSpillCalleeSavedRegs a member function, instead of passing most of the members of PEI as arguments. Differential Revision: https://reviews.llvm.org/D35642 llvm-svn: 308555
* [PEI] Separate saving and restoring CSRs into different functions. NFCFrancis Visoiu Mistrih2017-07-191-66/+51
| | | | | | | | | | | Split insertCSRSpillsAndRestores into insertCSRSaves + insertCSRRestores. This is mostly useful for future shrink-wrapping improvements where we want to save / restore a specific part of the CSRs in a specific block. Differential Revision: https://reviews.llvm.org/D35644 llvm-svn: 308554
* Revert "r306529 - [X86] Correct dwarf unwind information in function epilogue"Daniel Jasper2017-06-291-4/+0
| | | | | | | | | | I am 99% sure that this breaks the PPC ASAN build bot: http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3112/steps/64-bit%20check-asan/logs/stdio If it doesn't go back to green, we can recommit (and fix the original commit message at the same time :) ). llvm-svn: 306676
* [X86] Correct dwarf unwind information in function epiloguePetar Jovanovic2017-06-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CFI instructions that set appropriate cfa offset and cfa register are now inserted in emitEpilogue() in X86FrameLowering. Majority of the changes in this patch: 1. Ensure that CFI instructions do not affect code generation. 2. Enable maintaining correct information about cfa offset and cfa register in a function when basic blocks are reordered, merged, split, duplicated. These changes are target independent and described below. Changed CFI instructions so that they: 1. are duplicable 2. are not counted as instructions when tail duplicating or tail merging 3. can be compared as equal Add information to each MachineBasicBlock about cfa offset and cfa register that are valid at its entry and exit (incoming and outgoing CFI info). Add support for updating this information when basic blocks are merged, split, duplicated, created. Add a verification pass (CFIInfoVerifier) that checks that outgoing cfa offset and register of predecessor blocks match incoming values of their successors. Incoming and outgoing CFI information is used by a late pass (CFIInstrInserter) that corrects CFA calculation rule for a basic block if needed. That means that additional CFI instructions get inserted at basic block beginning to correct the rule for calculating CFA. Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D18046 llvm-svn: 306529
OpenPOWER on IntegriCloud