I think the best solution here is definitely to let the backend handle
outlining handler functions: to get reasonable code, the outlining has to be
done by something that understands the layout of the outer function's frame,
and only the backend can do that. No high-level intrinsic can capture the
relationship between the functions in any sort of reliable way without
completely disabling inlining of the outer function. And we really want to
still be able to do data-flow optimizations in the outer function; we just have
to ensure that any live-in values have been spilled to the stack at the call
site.
Unfortunately, I think the same principle is going to end up applying to filter
functions. If they don't use values from the enclosing frame, then fine, you
can outline them in the frontend; but if they do there's just no way that a
frontend solution is ever going to work. This might mean that we need to
change the invoke IR pattern again so that the filter functions are just basic
blocks within the function (which end in some special intrinsic/instruction
that guides outlining).
I think you need to have that conversation on the LLVM side before you can make
any useful progress on the Clang side. Please CC me on that conversation when
you start it.
================
Comment at: lib/CodeGen/CGException.cpp:113
@@ +112,3 @@
+ CGM.getTarget().getCXXABI().isItaniumFamily()) {
+ name = "_ZSt9terminatev";
+ } else if (CGM.getLangOpts().ObjC1 &&
----------------
Seems like a reasonable thing for the CXXABI to return.
================
Comment at: lib/CodeGen/CGException.cpp:437
@@ +436,3 @@
+ const EHPersonality &P = EHPersonality::get(CGM);
+ return StringRef("__C_specific_handler") == P.PersonalityFn;
+}
----------------
Don't do this. Make a flag somehow.
http://reviews.llvm.org/D5607
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
