[PATCH] D12108: [WinEH] Require token linkage in EH pad/ret signatures

[Reid Kleckner via llvm-commits]

rnk added a comment.

Oh, shoot, undef. I think we may be able to get by without allowing undef then. LLVM's main utility for removing unreachable code is removeUnreachableBlocks(), and it doesn't do RAUW(undef). I think it assumes that if something is unreachable, then all direct uses of it must also be unreachable, since they must be dominated by unreachable code. Because of the token type rules, the EH pads will always dominate their EH return instructions, and they'll all get knocked out at once.


================
Comment at: docs/LangRef.rst:5197-5198
@@ +5196,4 @@
+-  It is undefined behavior for control to transfer from a ``catchpad`` to
+   itself without first executing a ``catchret`` that consumes the
+   ``catchpad``'s value (counting instances in of the same ``catchpad`` in
+   different call frames as distinct).
----------------
JosephTremoulet wrote:
> rnk wrote:
> > s/consumes the catchpad's value/consumes the catchpad/ maybe?
> > 
> > I don't think the parenthetical makes this any clearer. WDYT?
> > s/consumes the catchpad's value/consumes the catchpad/ maybe?
> Yeah, that's better, will update.
> 
> > I don't think the parenthetical makes this any clearer. WDYT?
> I wish the parenthetical were more clear, but I think the sentence would be incorrect without it.  I need EH Prep to be able to assume that there isn't a cycle from a pad to itself in a single function, but entering the same pad twice is of course totally fine in different activations of a recursive function.  I'd be happy to reword if you have a suggestion that makes it clear.  And I can remove the parenthetical if you think it's obvious that the recursive case is allowed, but that was my thinking.
> 
I think the recursive case is eliminated because the recursive call would produce and consume a new catchpad value, sort of like how re-executing the same alloca in a recursive frame gives you new stack memory.


http://reviews.llvm.org/D12108