Displaying 5 results from an estimated 5 matches for "endcleanup".
2015 May 20
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...is
nesting inside SEH __finally blocks, at which point I'm pretty OK letting
that get bloated. If we're not going to use the construct in Clang, LLVM
passes won't see it as often, and it'll stay buggy longer.
The version of this feature that I like so far is probably entercleanup /
endcleanup, something along these lines:
try {
f(1);
} finally {
f(2);
}
invoke void @f(i32 1)
to label %cont unwind label %cleanup
cont:
entercleanup label %cleanup
return:
ret void
cleanup:
cleanupblock ; unwind label would go here if there were an action
call void @f(i32 2)
endcleanup...
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...I'm
> suggesting to cleanup-ending terminators are a mix between recover and
> unwind… FWIW, 'endfinally' would be a natural name for that in my world J.
> Personally I wouldn't hate something verbose like recover_or_unwind for the
> forms that may be doing either. 'endcleanup' also comes to mind.).
>
>
>
> Thanks
>
> -Joseph
>
>
>
>
>
> *From:* Reid Kleckner [mailto:rnk at google.com]
> *Sent:* Tuesday, May 19, 2015 3:40 PM
> *To:* Joseph Tremoulet
> *Cc:* LLVM Developers Mailing List; Bill Wendling; Nick Lewycky; Kaylor,...
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...g like
> 'unwinddispatch' or 'continuedispatch' or 'resumedispatch' and the resume
> that returns to normal execution could be 'exitdispatch' or 'exitcatch' or
> even 'uncatch'.
>
> For the resumes that end cleanups, something like 'endcleanup' might work.
>
> Names are hard…
>
'dispatch' might work for the instruction which transitions from a cleanup
to the next EH block. :) I don't really see how to work filter in,
especially since we've already used it for landingpad filters, which exist
to support except...
2015 May 18
4
[LLVMdev] New EH representation for MSVC compatibility
On Fri, May 15, 2015 at 5:27 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:
> I like the way this sorts out with regard to funclet code generation.
> It feels very natural for Windows EH, though obviously not as natural for
> non-Windows targets and I think it is likely to block some optimizations
> that are currently possible with those targets.
>
Right, it will
2015 May 18
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
On Mon, May 18, 2015 at 12:03 PM, Joseph Tremoulet <jotrem at microsoft.com>
wrote:
> Hi,
>
>
>
> Thanks for sending this out. We're looking forward to seeing this come
> about, since we need funclet separation for LLILC as well (and I have
> cycles to spend on it, if that would be helpful).
>
>
>
> Some questions about the new proposal:
>
>
>