[llvm] r258273 - [Inliner/WinEH] Honor implicit nounwinds

[Hans Wennborg via llvm-commits]

David, is this OK for 3.8? The PR is marked as a potential release blocker.

On Tue, Jan 19, 2016 at 6:15 PM, Joseph Tremoulet via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> Author: josepht
> Date: Tue Jan 19 20:15:15 2016
> New Revision: 258273
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258273&view=rev
> Log:
> [Inliner/WinEH] Honor implicit nounwinds
>
> Summary:
> Funclet EH tables require that a given funclet have only one unwind
> destination for exceptional exits.  The verifier will therefore reject
> e.g. two cleanuprets with different unwind dests for the same cleanup, or
> two invokes exiting the same funclet but to different unwind dests.
> Because catchswitch has no 'nounwind' variant, and because IR producers
> are not *required* to annotate calls which will not unwind as 'nounwind',
> it is legal to nest a call or an "unwind to caller" catchswitch within a
> funclet pad that has an unwind destination other than caller; it is
> undefined behavior for such a call or catchswitch to unwind.
>
> Normally when inlining an invoke, calls in the inlined sequence are
> rewritten to invokes that unwind to the callsite invoke's unwind
> destination, and "unwind to caller" catchswitches in the inlined sequence
> are rewritten to unwind to the callsite invoke's unwind destination.
> However, if such a call or "unwind to caller" catchswitch is located in a
> callee funclet that has another exceptional exit with an unwind
> destination within the callee, applying the normal transformation would
> give that callee funclet multiple unwind destinations for its exceptional
> exits.  There would be no way for EH table generation to determine which
> is the "true" exit, and the verifier would reject the function
> accordingly.
>
> Add logic to the inliner to detect these cases and leave such calls and
> "unwind to caller" catchswitches as calls and "unwind to caller"
> catchswitches in the inlined sequence.
>
> This fixes PR26147.
>
>
> Reviewers: rnk, andrew.w.kaylor, majnemer
>
> Subscribers: alexcrichton, llvm-commits
>
> Differential Revision: http://reviews.llvm.org/D16319