[llvm-commits] [Patch] New EH CodeGen

[Jakob Stoklund Olesen]

On Aug 2, 2011, at 11:30 AM, Bill Wendling wrote:

> On Aug 2, 2011, at 11:18 AM, Jakob Stoklund Olesen wrote:
> 
>> It looks like your patch is taking the same approach to codegen as before. That is only a temporary thing, right?
>> 
> Yes. I'm leveraging the existing system to get basic functionality down first. :)

That's fine. Codegen can be cleaned up later.

>> I think landing pads should be handled the same way we deal with the entry block. The values returned by the landingpad instruction are just like incoming function arguments. ISD::EXCEPTIONADDR and ISD::EHSELECTION shouldn't be necessary.
>> 
> Okay. I will try to avoid using them.

LegalizeDAG turns them into CopyFromRegs:

  case ISD::EHSELECTION: {
    unsigned Reg = TLI.getExceptionSelectorRegister();
    assert(Reg && "Can't expand to unknown register!");
    Results.push_back(DAG.getCopyFromReg(Node->getOperand(1), dl, Reg,
                                         Node->getValueType(0)));
    Results.push_back(Results[0].getValue(1));
    break;
  }
  case ISD::EXCEPTIONADDR: {
    unsigned Reg = TLI.getExceptionAddressRegister();
    assert(Reg && "Can't expand to unknown register!");
    Results.push_back(DAG.getCopyFromReg(Node->getOperand(0), dl, Reg,
                                         Node->getValueType(0)));
    Results.push_back(Results[0].getValue(1));
    break;
  }

This is dangerous because these nodes aren't glued to the landing pad entry. The scheduler might clobber %rax or %rdx before it gets to these nodes.

Incoming function arguments are handled differently. COPY instructions are inserted at the top of the entry block that copies argument registers to virtual registers. The selection DAG then uses CopyFromReg of the virtual registers which is safe.

I don't think any targets are custom expanding these nodes. Would any target need to?

/jakob