[LLVMdev] RFC: Exception Handling Rewrite

[Jakob Stoklund Olesen]

On Jul 23, 2011, at 4:15 PM, Bill Wendling wrote:

> On Jul 23, 2011, at 2:00 AM, Jakob Stoklund Olesen wrote:

>> Yes. You scared me with 'requires considerable care'. Does that mean anything other than 'you have to duplicate the landing pad instead of splitting the unwind edge'. Is special magic required to duplicate a landingpad instruction?
>> 
> There shouldn't be any special magic involved. As you pointed out, we'd have to duplicate the landingpad instruction into each of the critical edge blocks.

That sounds good to me. It's not necessary that SplitCriticalEdge can do it, I just want to be able to duplicate a landing pad without knowing the details of any particular personality function.

>>> In general, the use of a value in the catch blocks will access that value via memory.
>> 
>> Because the register allocator will spill, or because mem2reg fails? Won't there be a lot of IR values live across an unwind edge after mem2reg?
>> 
> The register allocator should be spilling most variables across the unwind edge. The only ones which can stick around are those that are placed in non-volatile registers. This is all opaque to the IR, which doesn't know that the unwind edge is special. This is why we can have PHI nodes in the landing pad. I'm assuming that it gets it "right" because it's keeping values alive across the invoke.

Yep, this should all just work. Unwind edges are just like any other critical edge, and the unwinder preserves the non-volatiles.

There is an optimization issue because once you stick a value in a non-volatile register across an unwind edge, that value must be in the same register before every call that shares the landing pad. That limits what live range splitting can do.

But this is really the register allocator's problem. I just want to make sure that it will be possible to duplicate those landing pads when they cause problems.

>>> It also complicates the SplitCriticalEdge function, like you outlined.
>> 
>> Yes, I agree. Duplicating a landing pad is different than splitting a critical edge.
>> 
>>>> Will it be possible to split landing pads during codegen?
>>> 
>>> Split a landing pad or split the critical edges to a landing pad?
>> 
>> Sorry, I meant duplicating a landing pad.
>> 
>> Landing pads notoriously collect critical edges. We should make sure there is some way of dealing with that, unlike indirectbr edges. The possibility of splitting and duplicating landing pads would help.
>> 
> One way to get around this is to do what Andy suggested to me at one point (not on email). We could have one landing pad block per invoke instruction. So no two invokes could ever share a landing pad (and of course the landingpad instruction). (My apologies to Andy if I misrepresented his idea.) I think of this as overkill, but if you feel strongly that not being able to break critical edges is going to hamper code-gen significantly we can discuss this.

It would certainly make many things easier, but I don't think we properly understand the code size impact of doing that. Low-frequency blocks without critical edges are like catnip to the splitter. It will put all the spill code in there, and we may not be able to merge those landing pads again.

I would like to keep the option, but I don't think we should aggressively duplicate landing pads.

I want to be able to split and duplicate landing pads on demand in IR and in MI. That is just as good as splitting critical edges. It sounds like your proposal allows this. We can discuss the MI representation when the time comes.

/jakob