aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/CFIInstrInserter.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-03-02[CFIInstrInserter] Don't store Dwarf register number in Register. NFCCraig Topper1-3/+3
2024-11-11[mc] Add CFI directive to emit val_offset() rules (#113971)Daniel Sanders1-0/+1
These specify that the value of the given register in the previous frame is the CFA plus some offset. This isn't very common but can be necessary if the original value is normally reconstructed from the stack/frame pointer instead of being saved on the stack and reloaded from there.
2024-10-28[AArch64][Libunwind] Add Support for FEAT_PAuthLR DWARF Instruction (#112171)Jack Styles1-0/+1
As part of FEAT_PAuthLR, a new DWARF Frame Instruction was introduced, `DW_CFA_AARCH64_negate_ra_state_with_pc`. This instructs Libunwind that the PC has been used with the signing instruction. This change includes three commits - Libunwind support for the newly introduced DWARF Instruction - CodeGen Support for the DWARF Instructions - Reversing the changes made in #96377. Due to `DW_CFA_AARCH64_negate_ra_state_with_pc`'s requirements to be placed immediately after the signing instruction, this would mean the CFI Instruction location was not consistent with the generated location when not using FEAT_PAuthLR. The commit reverses the changes and makes the location consistent across the different branch protection options. While this does have a code size effect, this is a negligible one. For the ABI information, see here: https://github.com/ARM-software/abi-aa/blob/853286c7ab66048e4b819682ce17f567b77a0291/aadwarf64/aadwarf64.rst#id23
2024-08-06Spill/restore FP/BP around instructions in which they are clobbered (#81048)weiguozhi1-6/+27
This patch fixes https://github.com/llvm/llvm-project/issues/17204. If a base pointer is used in a function, and it is clobbered by an instruction (typically an inline asm), current register allocator can't handle this situation, so BP becomes garbage after those instructions. It can also occur to FP in theory. We can spill and reload FP/BP registers around those instructions. But normal spill/reload instructions also use FP/BP, so we can't spill them into normal spill slots, instead we spill them into the top of stack by using SP register.
2024-07-23[LLVM] [MC] Update frame layout & CFI generation to handle frames larger ↵Wesley Wiser1-5/+5
than 2gb (#99263) Rebase of #84114. I've only included the core changes to frame layout calculation & CFI generation which sidesteps the regressions found after merging #84114. Since these changes are a necessary precursor to the overall fix and are themselves slightly beneficial as CFI is now generated correctly, I think it is reasonable to merge this first step. --- For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code. This patch updates the frame lowering code to calculate the offsets as 64-bit values and fixes CFI to use the corrected sizes. After this patch, additional work is needed to fix offset truncations in each target's codegen.
2024-07-07[MC] Support .cfi_labelFangrui Song1-0/+1
GNU assembler 2.26 introduced the .cfi_label directive. It does not expand to any CFI instructions, but defines a label in .eh_frame/.debug_frame, which can be used by runtime patching code to locate the FDE. .cfi_label is not allowed for CIE's initial instructions, and can therefore be used to force the next instruction to be placed in a FDE instead of a CIE. In glibc since 2018, sysdeps/riscv/start.S utilizes .cfi_label to force DW_CFA_undefined to be placed in a FDE. arc/csky/loongarch ports have copied this use. ``` .cfi_startproc // DW_CFA_undefined is allowed for CIE's initial instructions. // Without .cfi_label, gas would place DW_CFA_undefined in a CIE. .cfi_label .Ldummy .cfi_undefined ra .cfi_endproc ``` No CFI instruction is associated with .cfi_label, so the `case MCCFIInstruction::OpLabel:` code in BOLT is unreachable and onlt to make -Wswitch happy. Close #97222 Pull Request: https://github.com/llvm/llvm-project/pull/97922
2024-03-27Revert rG58de1e2c5eee548a9b365e3b1554d87317072ad9 "Fix stack layout for ↵Simon Pilgrim1-5/+5
frames larger than 2gb (#84114)" This is failing on some EXPENSIVE_CHECKS buildbots
2024-03-27Fix stack layout for frames larger than 2gb (#84114)Wesley Wiser1-5/+5
For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code. This patch updates the frame lowering code to calculate the offsets as 64-bit values and resolves the overflows, resulting in the correct codegen for very large frames. Fixes #48911
2023-11-09[CFIInstrInserter] Use number of supported registers (NFC) (#71797)Nikita Popov1-2/+2
This makes use of the more accurate register number introduced in PR #70222 to avoid CFI calculations for unsupported registers. This has basically no impact right now, but results in a 0.2% compile-time improvement at O0 when applied on top of #70958. The reason is that the extra registers that PR adds push the `BitVector` out of the `SmallVector` space, which results in an outsized impact. (This does make me wonder whether `BitVector` should accept an `N` template parameter to allow using a larger `SmallVector`...)
2023-05-23[X86] Use the CFA when appropriate for better variable locations around calls.Kyle Huey1-1/+2
Without frame pointers, the locations of variables on the stack are emitted relative to the stack pointer (via the stack pointer being the value of DW_AT_frame_base on the subprogram). If a call modifies the stack pointer this results in the locations being wrong and the debugger displaying the wrong values for variables. By using DW_OP_call_frame_cfa in these situations the emitted location for the variable will automatically handle changes in the stack pointer (provided LLVM is emitting the correct CFI directives elsewhere, of course). The CFA needs to be adjusted for the size of the stack frame (including the return address) to allow the variable locations themselves to remain unchanged by this patch. Certain LLDB features cannot cope with DW_OP_call_frame_cfa, so this change is heuristically limited to the cases where it's necessary for correctness to minimize the fallout there. Reviewed By: #debug-info, scott.linder, jryans, jmorse Differential Revision: https://reviews.llvm.org/D143463
2022-12-13[CodeGen] llvm::Optional => std::optionalFangrui Song1-6/+5
2022-12-07[NFC] Use Register instead of unsigned for variables that receive a Register ↵Gregory Alfonso1-1/+1
object Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D139451
2022-03-16Cleanup codegen includesserge-sans-paille1-3/+1
This is a (fixed) recommit of https://reviews.llvm.org/D121169 after: 1061034926 before: 1063332844 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121681
2022-03-10Revert "Cleanup codegen includes"Nico Weber1-1/+3
This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20. Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang, and many LLVM tests, see comments on https://reviews.llvm.org/D121169
2022-03-10Cleanup codegen includesserge-sans-paille1-3/+1
after: 1061034926 before: 1063332844 Differential Revision: https://reviews.llvm.org/D121169
2022-01-10[CodeGen] Rename emitCalleeSavedFrameMovesAlexander Shaposhnikov1-1/+1
This diff renames emitCalleeSavedFrameMoves to avoid conflicts with non-virtual methods of derived classes having the same name but different semantics. E.g. the class AArch64FrameLowering used to have (non-virtual) "emitCalleeSavedFrameMoves" but it started to override TargetFrameLowering::emitCalleeSavedFrameMoves after https://github.com/llvm/llvm-project/commit/c3e6555616 though its usage and semantics didn't change. P.S. for x86 there was no conflict because the signature of non-virtual X86FrameLowering::emitCalleeSavedFrameMoves is different Test plan: make check-all Differential revision: https://reviews.llvm.org/D114140
2021-06-14Implement DW_CFA_LLVM_* for Heterogeneous DebuggingRamNalamothu1-0/+8
Add support in MC/MIR for writing/parsing, and DebugInfo. This is part of the Extensions for Heterogeneous Debugging defined at https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html Specifically the CFI instructions implemented here are defined at https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#cfa-definition-instructions Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D76877
2021-03-23Introduce a generic operator to apply complex operations to BitVectorserge-sans-paille1-7/+8
This avoids temporary and memcpy call when computing large expressions. It's basically some kind of poor man's expression template, but it seems easier to maintain to have a single generic `apply` call instead of the whole expression template machinery here. Differential Revision: https://reviews.llvm.org/D98176
2021-03-08[NFC] Avoid useless BitVector moveserge-sans-paille1-2/+1
2020-07-14Call Frame Information (CFI) Handling for Basic Block SectionsKrzysztof Pszeniczny1-20/+31
This patch handles CFI with basic block sections, which unlike DebugInfo does not support ranges. The DWARF standard explicitly requires emitting separate CFI Frame Descriptor Entries for each contiguous fragment of a function. Thus, the CFI information for all callee-saved registers (possibly including the frame pointer, if necessary) have to be emitted along with redefining the Call Frame Address (CFA), viz. where the current frame starts. CFI directives are emitted in FDE’s in the object file with a low_pc, high_pc specification. So, a single FDE must point to a contiguous code region unlike debug info which has the support for ranges. This is what complicates CFI for basic block sections. Now, what happens when we start placing individual basic blocks in unique sections: * Basic block sections allow the linker to randomly reorder basic blocks in the address space such that a given basic block can become non-contiguous with the original function. * The different basic block sections can no longer share the cfi_startproc and cfi_endproc directives. So, each basic block section should emit this independently. * Each (cfi_startproc, cfi_endproc) directive will result in a new FDE that caters to that basic block section. * Now, this basic block section needs to duplicate the information from the entry block to compute the CFA as it is an independent entity. It cannot refer to the FDE of the original function and hence must duplicate all the stuff that is needed to compute the CFA on its own. * We are working on a de-duplication patch that can share common information in FDEs in a CIE (Common Information Entry) and we will present this as a follow up patch. This can significantly reduce the duplication overhead and is particularly useful when several basic block sections are created. * The CFI directives are emitted similarly for registers that are pushed onto the stack, like callee saved registers in the prologue. There are cfi directives that emit how to retrieve the value of the register at that point when the push happened. This has to be duplicated too in a basic block that is floated as a separate section. Differential Revision: https://reviews.llvm.org/D79978
2020-05-23[CFIInstrInserter] Delete unneeded checksFangrui Song1-7/+1
2020-05-22[MC] Change MCCFIInstruction::createDefCfaOffset to cfiDefCfaOffset which ↵Fangrui Song1-3/+2
does not negate Offset The negative Offset has caused a bunch of problems and confused quite a few call sites. Delete the unneeded negation and fix all call sites.
2020-05-22[MC] Change MCCFIInstruction::createDefCfa to cfiDefCfa which does not ↵Fangrui Song1-3/+3
negate Offset The negative Offset has caused a bunch of problems and confused quite a few call sites. Delete the unneeded negation and fix all call sites.
2020-04-27Recommit "Generate Callee Saved Register (CSR) related cfi directivesWei Mi1-10/+119
like .cfi_restore" Insert .cfi_offset/.cfi_register when IncomingCSRSaved of current block is larger than OutgoingCSRSaved of its previous block. Original commit message: https://reviews.llvm.org/D42848 only handled CFA related cfi directives but didn't handle CSR related cfi. The patch adds the CSR part. Basically it reuses the framework created in D42848. For each basicblock, the patch tracks which CSR set have been saved at its CFG predecessors's exits, and compare the CSR set with the set at its previous basicblock's exit (The previous block is the block laid before the current block). If the saved CSR set at its previous basicblock's exit is larger, .cfi_restore will be inserted. The patch also generates proper .cfi_restore in epilogue to make sure the saved CSR set is consistent for the incoming edges of each block. Differential Revision: https://reviews.llvm.org/D74303
2020-03-19Revert "Generate Callee Saved Register (CSR) related cfi directives like ↵Wei Mi1-66/+10
.cfi_restore." This reverts commit 3c96d01d2e3de63304ca3429d349ec62ae2adef3. Got report that it caused test failures in libc++.
2020-03-04Generate Callee Saved Register (CSR) related cfi directives like .cfi_restore.Wei Mi1-10/+66
https://reviews.llvm.org/D42848 only handled CFA related cfi directives but didn't handle CSR related cfi. The patch adds the CSR part. Basically it reuses the framework created in D42848. For each basicblock, the patch tracks which CSR set have been saved at its CFG predecessors's exits, and compare the CSR set with the set at its previous basicblock's exit (The previous block is the block laid before the current block). If the saved CSR set at its previous basicblock's exit is larger, .cfi_restore will be inserted. The patch also generates proper .cfi_restore in epilogue to make sure the saved CSR set is consistent for the incoming edges of each block. Differential Revision: https://reviews.llvm.org/D74303
2019-11-13Sink all InitializePasses.h includesReid Kleckner1-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
2019-10-31[cfi] Add flag to always generate .debug_frameDavid Candler1-2/+1
This adds a flag to LLVM and clang to always generate a .debug_frame section, even if other debug information is not being generated. In situations where .eh_frame would normally be emitted, both .debug_frame and .eh_frame will be used. Differential Revision: https://reviews.llvm.org/D67216
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-12-18[AArch64] - Return address signing dwarf supportLuke Cheeseman1-0/+1
- Reapply changes intially introduced in r343089 - The archtecture info is no longer loaded whenever a DWARFContext is created - The runtimes libraries (santiziers) make use of the dwarf context classes but do not intialise the target info - The architecture of the object can be obtained without loading the target info - Adding a method to the dwarf context to get this information and multiplex the string printing later on Differential Revision: https://reviews.llvm.org/D55774 llvm-svn: 349472
2018-11-23Revert r347490 as it breaks address sanitizer buildsLuke Cheeseman1-1/+0
llvm-svn: 347499
2018-11-23Revert r343341Luke Cheeseman1-0/+1
- Cannot reproduce the build failure locally and the build logs have been deleted. llvm-svn: 347490
2018-09-28Revert r343317Luke Cheeseman1-1/+0
- asan buildbots are breaking and I need to investigate the issue llvm-svn: 343341
2018-09-28Reapply changes reverted by r343235Luke Cheeseman1-0/+1
- Add fix so that all code paths that create DWARFContext with an ObjectFile initialise the target architecture in the context - Add an assert that the Arch is known in the Dwarf CallFrameString method llvm-svn: 343317
2018-09-27Revert r343192 as an ubsan build is currently failingLuke Cheeseman1-1/+0
llvm-svn: 343235
2018-09-27Reapply changes reverted in r343114, lldb patch to follow shortlyLuke Cheeseman1-0/+1
llvm-svn: 343192
2018-09-26Revert r343112 as CallFrameString API change has broken lldb buildsLuke Cheeseman1-1/+0
llvm-svn: 343114
2018-09-26[AArch64] - Return address signing dwarf supportLuke Cheeseman1-0/+1
- Reapply r343089 with a fix for DebugInfo/Sparc/gnu-window-save.ll llvm-svn: 343112
2018-09-26Revert r343089 "[AArch64] - Return address signing dwarf support"Hans Wennborg1-1/+0
This caused the DebugInfo/Sparc/gnu-window-save.ll test to fail. > Functions that have signed return addresses need additional dwarf support: > - After signing the LR, and before authenticating it, the LR register is in a > state the is unusable by a debugger or unwinder > - To account for this a new directive, .cfi_negate_ra_state, is added > - This directive says the signed state of the LR register has now changed, > i.e. unsigned -> signed or signed -> unsigned > - This directive has the same CFA code as the SPARC directive GNU_window_save > (0x2d), adding a macro to account for multiply defined codes > - This patch matches the gcc implementation of this support: > https://patchwork.ozlabs.org/patch/800271/ > > Differential Revision: https://reviews.llvm.org/D50136 llvm-svn: 343103
2018-09-26[AArch64] - Return address signing dwarf supportLuke Cheeseman1-0/+1
Functions that have signed return addresses need additional dwarf support: - After signing the LR, and before authenticating it, the LR register is in a state the is unusable by a debugger or unwinder - To account for this a new directive, .cfi_negate_ra_state, is added - This directive says the signed state of the LR register has now changed, i.e. unsigned -> signed or signed -> unsigned - This directive has the same CFA code as the SPARC directive GNU_window_save (0x2d), adding a macro to account for multiply defined codes - This patch matches the gcc implementation of this support: https://patchwork.ozlabs.org/patch/800271/ Differential Revision: https://reviews.llvm.org/D50136 llvm-svn: 343089
2018-08-30Allow inconsistent offsets for 'noreturn' basic blocks when '-verify-cfiinstrs'Vladimir Stefanovic1-0/+4
With r295105, some 'noreturn' blocks (those that don't return and have no successors) may be merged. If such blocks' predecessors have different outgoing offset or register, don't report an error in CFIInstrInserter verify(). Thanks to Vlad Tsyrklevich for reporting the issue. Differential Revision: https://reviews.llvm.org/D51161 llvm-svn: 341087
2018-05-11Use iteration instead of recursion in CFIInserterSanjoy Das1-15/+26
Summary: This recursive step can overflow the stack. Reviewers: djokov, petarj Subscribers: mcrosier, jlebar, bixia, llvm-commits Differential Revision: https://reviews.llvm.org/D46671 llvm-svn: 332101
2018-05-07Add option -verify-cfiinstrs to run verifier in CFIInstrInserterPetar Jovanovic1-5/+11
Instead of enabling it for non NDEBUG builds, use -verify-cfiinstrs to run verifier in CFIInstrInserter. It defaults to false. Differential Revision: https://reviews.llvm.org/D46444 llvm-svn: 331635
2018-05-07Skip unreachable blocks for CFIInstrInserter verifyPetar Jovanovic1-3/+4
Iterate only through reachable blocks. This finetunes r330706 and it resolves build issue reported by Craig Topper. llvm-svn: 331628
2018-04-24Correct dwarf unwind information in function epiloguePetar Jovanovic1-0/+308
This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives 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. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2017-11-08Revert "Correct dwarf unwind information in function epilogue for X86"Reid Kleckner1-319/+0
This reverts r317579, originally committed as r317100. There is a design issue with marking CFI instructions duplicatable. Not all targets support the CFIInstrInserter pass, and targets like Darwin can't cope with duplicated prologue setup CFI instructions. The compact unwind info emission fails. When the following code is compiled for arm64 on Mac at -O3, the CFI instructions end up getting tail duplicated, which causes compact unwind info emission to fail: int a, c, d, e, f, g, h, i, j, k, l, m; void n(int o, int *b) { if (g) f = 0; for (; f < o; f++) { m = a; if (l > j * k > i) j = i = k = d; h = b[c] - e; } } We get assembly that looks like this: ; BB#1: ; %if.then Lloh3: adrp x9, _f@GOTPAGE Lloh4: ldr x9, [x9, _f@GOTPAGEOFF] mov w8, wzr Lloh5: str wzr, [x9] stp x20, x19, [sp, #-16]! ; 8-byte Folded Spill .cfi_def_cfa_offset 16 .cfi_offset w19, -8 .cfi_offset w20, -16 cmp w8, w0 b.lt LBB0_3 b LBB0_7 LBB0_2: ; %entry.if.end_crit_edge Lloh6: adrp x8, _f@GOTPAGE Lloh7: ldr x8, [x8, _f@GOTPAGEOFF] Lloh8: ldr w8, [x8] stp x20, x19, [sp, #-16]! ; 8-byte Folded Spill .cfi_def_cfa_offset 16 .cfi_offset w19, -8 .cfi_offset w20, -16 cmp w8, w0 b.ge LBB0_7 LBB0_3: ; %for.body.lr.ph Note the multiple .cfi_def* directives. Compact unwind info emission can't handle that. llvm-svn: 317726
2017-11-08Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie1-1/+1
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
2017-11-07Reland "Correct dwarf unwind information in function epilogue for X86"Petar Jovanovic1-0/+319
Reland r317100 with minor fix regarding ComputeCommonTailLength function in BranchFolding.cpp. Skipping top CFI instructions block needs to executed on several more return points in ComputeCommonTailLength(). Original r317100 message: "Correct dwarf unwind information in function epilogue for X86" This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: - CFI instructions do not affect code generation - Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Changed CFI instructions so that they: - are duplicable - are not counted as instructions when tail duplicating or tail merging - can be compared as equal Added CFIInstrInserter pass: - analyzes each basic block to determine cfa offset and register valid at its entry and exit - verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors - inserts additional CFI directives 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. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. llvm-svn: 317579
2017-11-01Revert "Correct dwarf unwind information in function epilogue for X86"Petar Jovanovic1-319/+0
This reverts r317100 as it introduced sanitizer-x86_64-linux-autoconf buildbot failure (build #15606). llvm-svn: 317136
2017-11-01Correct dwarf unwind information in function epilogue for X86Petar Jovanovic1-0/+319
This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: - CFI instructions do not affect code generation - Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Changed CFI instructions so that they: - are duplicable - are not counted as instructions when tail duplicating or tail merging - can be compared as equal Added CFIInstrInserter pass: - analyzes each basic block to determine cfa offset and register valid at its entry and exit - verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors - inserts additional CFI directives 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. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D35844 llvm-svn: 317100
generated by cgit v1.1 at 2025-09-30 12:06:28 +0000