search for: entercleanup

...is if someone 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)...

...ld turn the branch to cleanupblock into a call > to the handler followed by a jump to the %normalsucc > > A change that I'd consider preferable since it avoids the need for an > auxiliary switch in the non-EH code would be: > > - some new terminator along the lines of 'entercleanup %cleanupblock > recover to %recoverblock', rather than a plain branch, can target > cleanupblocks > > - the resume/unwind terminator that ends a cleanup would have any > number of additional successors, and just like the rule that the EH target > must match the %nextaction...

On Mon, May 18, 2015 at 8:40 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > > I want to have separate normal and exceptional codepaths > > I assume you at least mean that's what you'll be doing in Clang's initial > IR generation. Do you also mean to impose this as a restriction on other > IR generators, and as a property that IR transformations must