[PATCH] D13451: [WinEH] Add CoreCLR EH table emission

[Joseph Tremoulet via llvm-commits]

JosephTremoulet marked an inline comment as done.

================
Comment at: lib/CodeGen/AsmPrinter/WinException.cpp:988-989
@@ +987,4 @@
+  // CLR EH "states" are really just IDs that identify handlers/funclets;
+  // states, handlers, and funclets all have 1:1 mappings between them, and
+  // a handler/funclet's "state" is its index in the ClrEHUnwindMap.
+  // The NullState is the special ID used to indicate unwinding to a caller
----------------
Updated, and yes that looks much nicer, thanks for the suggestion.

================
Comment at: lib/CodeGen/AsmPrinter/WinException.cpp:1110
@@ +1109,3 @@
+        auto StateAndEnd = FuncInfo.InvokeToStateMap.find(Label);
+        if (StateAndEnd == FuncInfo.InvokeToStateMap.end())
+          continue;
----------------
I'm not eager to switch to the `invoke_ranges` API as-is, since it only gets me within-MBB merging (so I still want merging up in this layer), and I find its `SawPotentiallyThrowing` state awkward to reason about.

I'd be happy to move to an iterator that
 - merges ranges across MBBs (I need to *not* merge ranges across funclets, so either the common iterator could take start/end and I could pass the appropriate MBBs, or it could unconditionally split at funclet boundaries and just walk the whole MF)
 - reports at each step:
    + the state entered at the new invoke range (-1 if entering a regions with potentially-throwing calls that aren't invokes, or if closing the final region)
    + the EH start label that starts the new invoke range (null if the entered state is -1)
    + the last EH end label that precedes the new range (so the caller can walk its stack of open clauses ending them there)

Would that be useful for generating the SEH tables?  I wouldn't mind taking a stab at refactoring both onto a shared iterator like that.

================
Comment at: test/CodeGen/WinEH/wineh-coreclr.ll:130
@@ +129,3 @@
+;                   ^ offset from L_begin to start of 1st funclet
+; CHECK-NEXT: .long [[L_catch2]]-[[L_begin]]
+;                   ^ offset from L_begin to start of 2nd funclet
----------------
We don't handle splitting out cold code yet in LLILC generally, so I'll cross that bridge when we get there :).


http://reviews.llvm.org/D13451