search for: terminateblock

Displaying 4 results from an estimated 4 matches for "terminateblock".

2015 Jul 01
2
[LLVMdev] New EH representation for MSVC compatibility
...r to build our EH support in LLILC on top of > this. > A preliminary step was to push personality routines off of LandingPadInst and onto functions, this is already in trunk. On the IR front, we ended up with the following set of instructions: catcblock, catchret, cleanupblock, cleanupret, terminateblock Of these, I've locally added basic support for catchblock, catchret and cleanupret. I'm working on cleanupblock and terminateblock as we speak. We'll still need to hook up CodeGenPrep and SDAG up to the new representation. Extra hands will be appreciated auditing LLVM's optimiza...
2015 May 15
8
[LLVMdev] RFC: New EH representation for MSVC compatibility
...eanupblock -------------------- %val = cleanupblock <valty> unwind label %nextaction This is not a terminator, and control is expected to flow into a resume instruction which indicates which EH block runs next. If the resume instruction and the unwind label disagree, behavior is undefined. terminateblock ---------------------- ; for noexcept terminateblock [void ()* @std.terminate] unwind label %nextaction ; for exception specifications, throw(int) terminateblock [void ()* @__cxa_unexpected, @typeid.int, ...] unwind label %nextaction This is a terminator, and the unwind label is where execution w...
2015 Jun 18
2
[LLVMdev] New EH representation for MSVC compatibility
On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at philipreames.com> wrote: > Since I haven't been following the thread closely, is there an updated > summary of the original proposal available? I know that various parts I > had concerns with (the unsplitable blocks for instance) got addressed, but > I'm having trouble tracking all the changes in discussion.
2015 May 18
4
[LLVMdev] New EH representation for MSVC compatibility
...wrong in this regard, unless I’m misunderstanding it. > It looks like any exceptions that aren’t caught in that function will lead > to a terminate call. > Well, those are the intended semantics of noexcept, unless I'm mistaken. And the inliner *should* wire up the unwind edge of the terminateblock to the unwind edge of the inlined invoke instruction, because it's natural to lower terminateblock to a catch-all plus termination call block. I wanted to express that as data, though, so that in the common case that the noexcept function is not inlined, we can simply flip the "noexcept&qu...