llvm dev - May 2015 - [LLVMdev] [WinEH] A hiccup for the Windows C++ exception handling

I made some progress this afternoon.  I now have a set of changes in my local
sandbox that allows clang to pass all of the tests in the suite I’ve been using
to exercise this code.

How do you feel about working these changes into trunk to establish a working
baseline, even knowing that parts of this are going to be redesigned?

-Andy

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Wednesday, May 13, 2015 2:16 PM
To: Kaylor, Andrew; David Majnemer
Cc: LLVM Developers Mailing List
Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling

Basically, I'm trying to come up with a good design doc with David right now
so I can mail it out. :)

On Wed, May 13, 2015 at 1:43 PM, Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
Have got anything started with the dispatchblock plan?

From: Reid Kleckner [mailto:rnk at google.com<mailto:rnk at google.com>]
Sent: Wednesday, May 13, 2015 1:15 PM
To: Kaylor, Andrew
Cc: David Majnemer <david.majnemer at gmail.com<mailto:david.majnemer at
gmail.com>> (david.majnemer at gmail.com<mailto:david.majnemer at
gmail.com>); LLVM Developers Mailing List
Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling

On Wed, May 13, 2015 at 11:03 AM, Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
So there are two issues here.

1) We need a better way to figure out which blocks should be in which handlers
and properly remap the return statements in each handler accordingly.
2) We need a better way to compute the EH states.

Anyway, I’m working on these problems right now.  I’m still trying to solve the
problems without redesigning our current scheme, but I don’t think this is going
to be the right long term solution.

Yeah, we're on the same page. The current scheme is not the right long term
solution. The SEH personality functions are not nearly as limiting. I was hoping
that, like with SEH, we could completely throw away the information about try
nesting and simply emit tables that are functionally correct. We knew it was
theoretically impossible to always recover the nested try structure from
Itanium-style landingpad IR, but now we know it is also *practically*
impossible. :)

Ultimately, I think something like the dispatchblock scheme I described will
work better.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150513/fc7f8bc8/attachment.html>

On Wed, May 13, 2015 at 4:37 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>
wrote:
>  I made some progress this afternoon.  I now have a set of changes in my
> local sandbox that allows clang to pass all of the tests in the suite I’ve
> been using to exercise this code.
>
>
>
> How do you feel about working these changes into trunk to establish a
> working baseline, even knowing that parts of this are going to be
> redesigned?
>
I guess I'm kind of ambivalent about continuing in the current direction.
It doesn't hurt, but if it provides someone with basic functionality for
now, then that's OK. On the other hand, the tests won't be particularly
valuable because Clang is going to emit new LLVM IR, so they'll need to be
redone.

I also think that, given that the rewrite will take at least a month, we
should turn MSVC C++ exceptions off by default in Clang until it's ready.
We need some hidden flag that isn't /EHs. I'm already tired of getting
bug
reports along the lines of "clang crashed while compiling MSVC-style
exceptions". Of course, the user can't tell from the crash that the
workaround is just "turn off exceptions until they work". =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150514/f5f52f1e/attachment.html>

I should clarify that the tests I’m talking about are compile-and-execute tests,
so they will still be relevant to the re-designed implementation. 
Unfortunately, I don’t have them integrated with any LLVM testing mechanism. 
That’s something else I’ve been meaning to ask about.

Anyway, I think the results I’m seeing now are fairly significant, so I’d like
to get these changes checked in -- especially given that it’s going to be a
month or more before an alternate approach is ready.  I’d also like to talk
about a transition plan so that we can minimize the backward steps taken as this
is redesigned.  Maybe a command line option to enable the new IR generation
until an end-to-end implementation is complete?

I’m working right now to clean up what I’ve done, but I should have it in a
reviewable state today.  After that, I’ll try to create some lit-based tests
that exercise the trouble spots that I am addressing.

I don’t have any objections to turning MSVC C++ exceptions off by default, but I
think it’s possible that with these changes that might not be necessary.

-Andy

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Thursday, May 14, 2015 9:12 AM
To: Kaylor, Andrew
Cc: David Majnemer; LLVM Developers Mailing List
Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling

On Wed, May 13, 2015 at 4:37 PM, Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
I made some progress this afternoon.  I now have a set of changes in my local
sandbox that allows clang to pass all of the tests in the suite I’ve been using
to exercise this code.

How do you feel about working these changes into trunk to establish a working
baseline, even knowing that parts of this are going to be redesigned?

I guess I'm kind of ambivalent about continuing in the current direction. It
doesn't hurt, but if it provides someone with basic functionality for now,
then that's OK. On the other hand, the tests won't be particularly
valuable because Clang is going to emit new LLVM IR, so they'll need to be
redone.

I also think that, given that the rewrite will take at least a month, we should
turn MSVC C++ exceptions off by default in Clang until it's ready. We need
some hidden flag that isn't /EHs. I'm already tired of getting bug
reports along the lines of "clang crashed while compiling MSVC-style
exceptions". Of course, the user can't tell from the crash that the
workaround is just "turn off exceptions until they work". =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150514/4c08bf85/attachment.html>