[PATCH] Outline functions for SEH with the MSVC environment

Andy Kaylor andrew.kaylor at intel.com
Thu Jan 15 15:54:30 PST 2015


> David suggested simply renaming this intrinsic to llvm.eh.selector.for(i8*) to generalize it over SEH. Continuing to use typeid is a bit crazy. Do you think it's better to generalize the typeid intrinsic or add a new special purpose intrinsic? We'd have to teach GVN about it.


I like the idea of a generalized selector intrinsics, but I have two problems that I'm not sure it solves.

1. I need a way to determine whether or not the outlining has already been done.  I suppose I could use the presence of calls to "llvm.eh.seh.filter" (or whatever else ends up in that place) to do that, but that's a new intrinsic too.  There's also still the problem of outlining the clean handlers (and recognizing when that has been done) and native Windows support for C++ EH.

2. I was kind of hoping to use a dead code elimination trick similar to what you suggested for the outlined functions to get rid of the filter code after it has been outlined.  I could possibly still do that if the filter dispatch and handler dispatch were calling the same intrinsic.  I haven't tried that out yet.

Having said that, both of these problems can probably be solved without having two different intrinsics that essentially mean the same thing just in different places.  So let me see if I can work this out with the general selector intrinsic.

I'll also think about the big picture a bit more and try to look ahead to how Windows support for C++ EH will fit into the plan.

> Yeah, I'm still not sure how to represent prepared cleanups in IR. Maybe just `@llvm.seh.cleanup(void ()* @mycleanup)`?


How would that be attached to the landing pad instruction?  Specifically, how would we find it when generating the .xdata table?


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D6556

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list