[PATCH] D18046: [X86] Providing correct unwind info in function epilogue

Kyle Butt via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 29 13:21:25 PDT 2017


iteratee added a comment.

In https://reviews.llvm.org/D18046#712052, @violetav wrote:

> Hi Kyle, thank you for commenting!
>  I am not sure that I fully understand what you are proposing.
>  Are you saying that we should attach info about incoming and outgoing cfa_offset and register to a MBB or actually add CFI instructions to the beginning and end of a MBB (and then remove unnecessary CFI instructions later)?


Attach the info

> Do you think that CFI instructions in epilogue should be inserted during frame lowering, when instructions that change the SP are created?

Yes.

> Same question for the store-to-push optimization.

Yes.

> The problem is that CFI instructions that are inserted earlier (before MBB reordering, merging, splitting, that is done in the later passes (tail duplication, control flow optimizer)) affect code generation.

They **currently** affect code generation. This is my biggest complaint. I don't see why they should affect these passes.

> If we add information about incoming and outgoing CFI offset and register to a MBB, we would definitely be more flexible. That would support multiple MBBs that change CFI offset (that have different CFI offset at their beginning and end) besides prologue and epilogue. However, the problem with CFI instructions impacting code generation would still be present, and would be handled similarly to the way it is handled in the proposed implementation. Do you have something else in mind for solving this issue?
>  What do you think is wrong with this approach?

I've answered above, but I'm still not convinced that CFI instructions, being only assembler directives to generate dwarf info should affect code generation. I think this is the big problem worth solving, and then the rest of the work will be small problems.


Repository:
  rL LLVM

https://reviews.llvm.org/D18046





More information about the llvm-commits mailing list