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

[Hans Wennborg via llvm-commits]

r258349. Thanks.

On Wed, Jan 20, 2016 at 12:35 PM, David Majnemer <majnemer at google.com> wrote:
> Yes, it's good to merge.
>
> On Wed, Jan 20, 2016 at 9:42 AM, Hans Wennborg <hans at chromium.org> wrote:
>>
>> 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
>
>