[PATCH] PR8541; X86: Handle unwind.init and eh.return intrinsics.

Jakob Stoklund Olesen stoklund at 2pi.dk
Wed May 15 10:11:08 PDT 2013


On May 14, 2013, at 5:20 PM, Pasi Parviainen <pasi.parviainen at iki.fi> wrote:

> On 15.5.2013 2:26, Jakob Stoklund Olesen wrote:
>> 
>> Is it important that the extra registers are not restored in non-eh.return epilogues? If not, a simpler implementation would simply spill all callee-saved registers in eh.return functions. This is essentially the workaround FreeBSD is using now by inserting inline assembly.
> 
> Yes, it is important not to restore those registers on non-eh.return epilogues, since restoring those registers might destroy return value of function on those paths (e.g. X86 uses eax and edx registers for exception information, and restoring eax would destroy return value set before epilogue).

Thanks for explaining, Pasi. I think I understand how it is supposed to work now, and how your patch works.

I would like to move as much as possible into target-independent code to avoid code duplication between targets.

- As you mentioned, callsUnwindInit() functions should spill all callee-saved registers, and that can be handled in PEI::calculateCalleeSavedRegisters(). Simply skip the isPhysRegUsed() test.

- You found a way of identifying the landing pad argument registers through getCallPreservedMask(). This code is a little too exciting to have duplicated in the targets, and I would like that to move into PEI as well. We could add a isEHReturnOnly() bit to the CalleeSavedInfo class that is computed in PEI. Then the targets would go:

  if (CSI[i].isEHReturnOnly() && !isEHReturnBlock(MBB)) {
    // Adjust stack instead of popping.
    ..
  }

I imagine that we may want to add a TargetRegisterInfo hook to identify the EH data registers one day, and this way the targets wouldn't need to change.

- Similarly, spilling of EH data registers in callsEHReturn() functions could also be handled in PEI::calculateCalleeSavedRegisters().

Thanks,
/jakob




More information about the llvm-commits mailing list