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

[Reid Kleckner via llvm-commits]

rnk added inline comments.

================
Comment at: lib/CodeGen/AsmPrinter/WinException.cpp:1110
@@ +1109,3 @@
+        auto StateAndEnd = FuncInfo.InvokeToStateMap.find(Label);
+        if (StateAndEnd == FuncInfo.InvokeToStateMap.end())
+          continue;
----------------
JosephTremoulet wrote:
> 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.
If you could take a stab at refactoring it, that'd be awesome. The SEH and C++ table emission would be simpler with the interface you described.

I don't think I did a particularly good job writing that adaptor. I think making it cross-MBB will actually fix a bug around SawPotentiallyThrowing that I added when doing that refactor... Oops.

================
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
----------------
JosephTremoulet wrote:
> We don't handle splitting out cold code yet in LLILC generally, so I'll cross that bridge when we get there :).
I mentioned this because I want to do this in WinException::endFunclet() as soon as possible. It'll be easy to turn off for the CLR personality for now. :)


http://reviews.llvm.org/D13451