Exception Handling Rewrite Branch

For those who are playing along, I've started on the exception handling rewrite following the document and comments from this thread:


The repositories are:


Progress Report:

  I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad instruction.


  I'll be working on getting inlining to work.

Feel free to respond with questions, comments, and concerns about the design. Also, please take some time to review the patches I submit.


I have nothing to contribute other than to ask if this rewrite will bring clang's -fno-exceptions behavior inline with GCC's. According to this comment: http://llvm.org/bugs/show_bug.cgi?id=9171#c5 clang disables both C++ and Objective-C exceptions with that option whereas GCC only disables them for C++. Of course, this may have already been fixed in clang in the 5 months since I reported that bug, and WebKit fixed the issue where it was cropping up for them, but I just wanted to bring it to your attention if you're going to specifically change how exceptions are implemented in clang.

Of course this could be completely irrelevant, so carry on.

Jon Shier

It is :slight_smile:

The exceptions rewrite concerns how exceptions are expressed in LLVM IR. It will have no effect on Clang's behavior, except hopefully to eliminate some miscompiles that have resisted our previous attempts to fix them.

  - Doug

<dropping cfe-dev>

Hi Chris,

Some of the changes (like the inliner changes) are going to break the old EH way of doing things. The front-ends will need to change over to the new EH scheme. And they won't want to change over until things are finished. It's a bit of a chicken-and-egg thing. I figured that doing this on a branch first and then outlining how to change the front-ends and/or create an Auto-upgrade tool would be the best course of action.


I would greatly prefer for you to implement the new instructions in mainline, and add the new inliner logic (under a flag if need-be). There should be no breakage for existing code until the frontends switch to generating the new EH stuff. This can also be done under a flag in clang for example.


Okay. I'll see what I can do.