[LLVMdev] WinEH work to be done (in progress and otherwise)

[Kaylor, Andrew]

What follows is primarily addressed to Reid and David, but since it some of it is relevant to the Windows exception handling proposal under discussion, I thought I should copy the LLVMDev distribution list.  Anyone interested should feel free to jump in and discuss.

My primary purpose here is to talk about what I'm working on so that anyone who is also working on the same things can let me know and avoid duplicated efforts.

Right now, in addition to the patch I have up on Phabricator to get 64-bit C++ EH mostly working with unoptimized IR, I have a couple of local changes that fix "failure to demote" problems with optimized IR.  My goal here has been to use the current implementation to discover what pitfalls remain that could give us problems in the future with any alternate implementation.  I still think the patch I have up for review is worth committing because it gets a lot of cases in a state where we can compile and execute correctly which serves as a useful point of comparison for the failures of the same cases when optimizations are applied.   I'm not sure about the other changes I just mentioned, as they are just delving further into untangling the mess we've gotten ourselves into.  I'll keep them around and would be happy to share them if anyone is interested, but I don't plan to push to commit them in the foreseeable future.

I'm shifting gears today, putting aside the optimization related problems, and have begun exploring 32-bit C++ EH support.  At least part of the work to be done here seems like it will remain relevant even after the current redesign comes to fruition and even what won't remain relevant looks like it will be interesting as input to the redesign.

Have either of you (Reid and David) looked closely at the 32-bit C++ EH case?  I saw the preliminary support in X86WinEHState, and I'm currently working on addressing the problem described in the FIXME comment there.  I had been under the impression that 32-bit C++ EH was pretty much just a matter of making the equivalent of the xdata tables accessible via the stack and everything would more or less fall into place.  Now that I'm taking a closer look it also appears that live code must be generated to keep the EH state updated -- at least that appears to be what MSVC is doing.

The live numbering of EH states is an interesting contrast to the ip2state table approach used in the x86_64 case, and it makes me wonder what complications would arise from trying to generate the EH state numbers in the front end.  Reid's recent RFC mentioned that, "The natural scoping rules of C++ make it so that doing this numbering at the source level is trivial, but once we go to LLVM IR CFG soup, scopes are gone."  So why not generate these numbers in the front end?  Would keeping them correct through the optimization passes require blocking too many useful optimizations?  Alternatively, can we insert this as part of the invoke lowering?

Apart from this, the other WinEH-related task that I have on my radar (but as of yet haven't done anything about) is getting "nightly" tests running on Windows.  I did look into the instructions for running the "test-suite" tests, and it looks like that test suite is assuming a Unix-type platform to some extent.  I tried to re-interpret the instruction and run this suite on Windows, but it didn't work and I haven't looked into trying to fix whatever the problems were.  I saw that someone submitted a patch last November that claimed to improve the running of these tests on Windows, but the patch was never reviewed or committed.

So I was wondering, is anyone running compile-and-execute type tests with clang on a native (i.e. non-cygwin/mingw) Windows platform?  It seems like this will be an important thing to do in general, but particularly so for Windows EH, dependent as it is on interaction with the runtime library.  That is, having tests which verify that we're producing the xdata entries we intend to produce doesn't seem like a very thorough method of testing and is no guarantee at all that we are producing working executables.  In addition to the existing C++ EH tests in the "test-suite" tests, I have a suite of tests (not currently in any public repository) that were specifically developed to exercise Windows-specific problem cases.  I'd eventually like to see these tests run on some regular basis against clang on Windows.  Is there any work currently under way to make something like this happen?

Thanks,
Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/34555378/attachment.html>