Cranelift: refactoring of unwind info

[yurydelendik]

This PR:

• Creates common unwind info data structures (at cranelift::isa::unwind::input)
• Extracts common logic for SystemV and FastCall into "cranelift/codegen/src/isa/x86/unwind.rs"
• Moves emit logic from cranelift/codegen/src/isa/x86/unwind/winx64.rs to cranelift/codegen/src/isa/unwind/winx64.rs
• Moves emit logic from cranelift/codegen/src/isa/x86/unwind/systemv.rs to cranelift/codegen/src/isa/unwind/systemv.rs
• Fixes test at x86/unwind/systemv.rs

This is a preparation PR to expose unwind info for different backends, e.g. new backend for Aarch64. Also, will be useful to move emitting logic out of the codegen crate and keep only common data structures.

See also #2266

[peterhuene]

Overall, the refactoring seems pretty straight-forward and most of my comments are simply about the naming of the ABI-agnostic names of the unwind operations.

I do have a concern about the performance of this change, primarily for Windows. The Windows x64 ABI only needs to look at the entry block to fully describe the unwind information because epilogues are not described for Windows x64. Epilogues on Windows x64 must have a specific form and Windows will detect an unwind inside of an epilogue and emulate the completion of the epilogue to unwind the function.

With these changes, the more complex scan needed to build DWARF CFI is used even on Windows. This includes sorting the blocks and then inspecting every instruction in the function. I would imagine this can be pretty expensive for modules with a lot of large functions. There's also now the additional allocations being done for building up this intermediary "ABI-agnostic" unwind information and then feeding it to the build function that transforms it to the "ABI-specific" unwind information.

Obviously these are merely concerns until some actual performance measurements are made, but it's something to think about.

Regarding Windows ARM64, I think this refactoring won't introduce any limitations for emitting unwind information 👍. Unlike Windows x64, the ARM64 unwind information does describe the epilogues, but in the majority case the epilogues are described in terms of the prologue (i.e. there would just be a set of unwind codes for the prologue and the epilogue unwind information would point at the same set of codes to indicate a "mirror" operation). However, this means the ARM64 unwind information will require the offset to the start of each epilogue within the function.

That said, I haven't looked at what the ARM backend emits for prologues and epilogues and whether or not it will emit noncontiguous functions (complicates the unwind information a little). If the ARM backend only ever emits "mirror" epilogues (i.e. an epilogue that has a 1:1 reverse instruction for each prologue instruction), then, as with the x64 unwind information, the Windows ARM64 unwind information would ever only need to look at the entry block.

[yurydelendik]

I do have a concern about the performance of this change, primarily for Windows. The Windows x64 ABI only needs to look at the entry block to fully describe the unwind information because epilogues are not described for Windows x64.

I improved performance of isa::x86::create_unwind_info by scanning only prologue and epilogue blocks, and better epilogues_start check. That's something between windows x64 and systemv unwind info performance speeds. Assuming that a majority of function will not have long entry and epilogue block, that shall be fine.

Nature of our generated code (even in systemv) does not require to have epilogues -- it is just correct to have them for e.g. step-by-step debugging. If the performance will be the issue, their generation can be removed without effect on backtrace logic.

I expect that new backends will allow us to know exact ranges of prologue/epilogue instructions.

[peterhuene]

Looks great! Storing the block with the epilogue starts definitely makes sense.