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

Francis Visoiu Mistrih via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 22 14:33:12 PDT 2017


thegameg added a comment.

Hi,

I see that your patch is mostly about the state of CFA, but I think this applies to other things, like callee-saved registers.

As part of my work on shrink-wrapping, I needed to add support for saving / restoring registers in multiple locations. So, in order to get correct CFI information for the registers, we have to add the corresponding `.cfi_offset` and `.cfi_restore` to the save and restore points, which results in the following code:

  // BLOCK0
  if (i) {
      // BLOCK1
      save reg1
      if (a) {
        // BLOCK2
        save reg2
        [... use reg1 reg2 ...]
        restore reg2
        restore reg1
        ret
      } else {
        // BLOCK3
        save reg3
        [... use only reg1, reg3 ...]
        restore reg3
        restore reg1
        ret
      }
  } else {
   // BLOCK4
   ret
  }

So, in this case, it's not correct to assume that the CFI state starts at the entry block, nor to assume that it is the same in the whole function (pretty much the same issue as CFA). For this, I emit a `CFI_INSTRUCTION .cfi_offset` along with every save, and a `CFI_INSTRUCTION .cfi_restore` along with every restore. After that, in the AsmPrinter I run another pass to fill the gaps and add more `.cfi_offset` or `.cfi_restore` where the fall through state is not correct.

Imagine the order of the basic blocks was:

  BLOCK0
  BLOCK1
  BLOCK4
  BLOCK2
  BLOCK3

then we need an extra `.cfi_restore reg1` at the end of `BLOCK1` and an extra `.cfi_offset reg1` at the beginning of `BLOCK2`.

This could currently happen with the current shrink-wrapping implementation, but the block placement is never placing blocks in a way that the prologue comes after the epilogue, so we didn't hit that issue yet.

I guess this issue can be also addressed with the same infrastructure you're building here for CFA. What do you think?

Also, I might be missing something here, but do we really need to maintain the state of CFA in every MBB starting from PEI to (almost) AsmPrinter? Can't we just do one simple pass during (or before) AsmPrinter which collects all the CFI directives and does the analysis based on the CFG and the final block layout (since at that point, we have that information) ? It looks like TailDuplication was the problem, but looks like you fixed that to skip CFI instructions.

Let me know what you think.


Repository:
  rL LLVM

https://reviews.llvm.org/D18046





More information about the llvm-commits mailing list