This change removes the `tidyLandingPads` function, which previously had a few responsibilities: 1. Dealing with the deletion of an invoke, after MachineFunction lowering. 2. Dealing with the deletion of a landing pad BB, after MachineFunction lowering. 3. Cleaning up the type-id list generated by `MachineFunction::addLandingPad`. Case 3 has been fixed in the generator, and the others are now handled during table emission. This change also removes `MachineFunction`'s `addCatchTypeInfo`, `addFilterTypeInfo`, and `addCleanup` helper fns, as they had a single caller, and being outlined didn't make it simpler. Finally, as calling `tidyLandingPads` was effectively the only thing `DwarfCFIExceptionBase` did, that class has been eliminated.
The existing behaviors and callbacks were overlapping and had very confusing semantics: beginBasicBlock/endBasicBlock were not always called, beginFragment/endFragment seemed like they were meant to mean the same thing, but were slightly different, etc. This resulted in confusing semantics, virtual method overloads, and control flow. Remove the above, and replace with new beginBasicBlockSection and endBasicBlockSection callbacks. And document them. These are always called before the first and after the last blocks in a function, even when basic-block-sections are disabled.
Follow-up to c031378ce01b8485ba0ef486654bc9393c4ac024 . The class is mostly consistent now.
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121332
Identified with modernize-use-equals-default
The ARM backend was explicitly setting global binding on the personality symbol. This was added without any comment in a7ec2dcefd954, which introduced EHABI support (back in 2011). None of the other backends do anything equivalent, as far as I can tell. This causes problems when attempting to wrap the personality symbol. Wrapped symbols are marked as weak inside LTO to inhibit IPO (see https://reviews.llvm.org/D33621). When we wrap the personality symbol, it initially gets weak binding, and then the ARM backend attempts to change the binding to global, which causes an error in MC because of attempting to change the binding of a symbol from non-global to global (the error was added in https://reviews.llvm.org/D90108). Simply drop the ARM backend's explicit global binding setting to fix this. This matches all the other backends, and a large internal application successfully linked and ran with this change, so it shouldn't cause any problems. Test via LLD, since wrapping is required to exhibit the issue. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D110609
In terms of readability, the `enum CFIMoveType` didn't better document what it intends to convey i.e. the type of CFI section that gets emitted. Reviewed By: dblaikie, MaskRay Differential Revision: https://reviews.llvm.org/D76519
This reverts commit 0ce723cb228bc1d1a0f5718f3862fb836145a333. D76519 was not quite NFC. If we see a CFISection::Debug function before a CFISection::EH one (-fexceptions -fno-asynchronous-unwind-tables), we may incorrectly pick CFISection::Debug and emit a `.cfi_sections .debug_frame`. We should use .eh_frame instead. This scenario is untested.
In terms of readability, the `enum CFIMoveType` didn't better document what it intends to convey i.e. the type of CFI section that gets emitted. Reviewed By: dblaikie, MaskRay Differential Revision: https://reviews.llvm.org/D76519
Emit{ValueTo,Code}Alignment Emit{DTP,TP,GP}* EmitSymbolValue etc