[LLVMdev] RFC: Exception Handling Rewrite

[Andrew Trick]

On Jul 23, 2011, at 5:00 PM, Jakob Stoklund Olesen wrote:
> 
> On Jul 23, 2011, at 4:15 PM, Bill Wendling wrote:
>>> 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

Sorry I neglected this. My original point to Bill was that we're taking on extra complexity in order to support shared landing pads. Yet the only obvious benefit is pretty IR, with some questionable benefit in compacting the bitcode.

The extra complexity is clear when you look at edge splitting. John explained it well. Clients of the edge splitter don't expect other edges to change. In general I think it's a bit harder to reason about shared landing pads. For example, it's strange to me to have phi nodes between the invoke and landing pad.

But now that I see how verbose the landing pads have become (because they're summarizing the cleanups and handlers too!), I think Bill did the right thing at the IR level. It would just be too gross to clone them everywhere.

Codegen is more interesting. We (hopefully) won't need any special EH placeholder instructions, and we'd like to be able to split edges anywhere, anytime prior to branch optimization.

I'm philisophically opposed to the argument that split landing pads gives the splitter too much freedom. They simply allow the splitter to do exactly what it was designed to do. I understand that we're currently using the presence of critical edges as a kind of heuristic to balance static code size with performance (note that with split edges, the splitter is reducing dynamic code size at the cost of more almost-never-taken unconditional branches). My concern is that the problem is broader than just EH code and we're avoiding a general solution. For example, I think it would be nice to have a branch optimizer run after regalloc and push instructions across edges to remove unconditional branches only when it makes sense for a particular subtarget. I would prefer to focus the effort on improving edge-splitting heuristics in that pass, rather than rely on each codegen pass to implement its own pathetic attempt at those heuristics. So, it would be nice to keep in mind that in the long-term Codegen doesn't *need* to support shared landing pads prior to branch optimization.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110803/7150d257/attachment.html>