search for: catchblocks

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

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,

...dressed, but > I'm having trouble tracking all the changes in discussion. Even just a > quick list of "and we changed X" would be helpful. > > > > We should do an updated summary, but I've been busy. > > > > We really do need to keep the unsplittable catchblocks, though. > Fundamentally, what we have is control flow described by data. This > proposal essentially adds LLVM instructions that model that data. We can't > insert real instructions like loads and stores between EH dispatch table > entries, so it's forbidden. > > > &gt...

...table blocks for instance) got addressed, but > I'm having trouble tracking all the changes in discussion. Even just a > quick list of "and we changed X" would be helpful. > We should do an updated summary, but I've been busy. We really do need to keep the unsplittable catchblocks, though. Fundamentally, what we have is control flow described by data. This proposal essentially adds LLVM instructions that model that data. We can't insert real instructions like loads and stores between EH dispatch table entries, so it's forbidden. We can compensate for all the other C...

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: > > >

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

I think adding transitions to cleanupblocks on the normal execution path would be an optimization barrier. Most passes would see the cleanupblock instruction and run the other way. It's definitely appealing from the perspective of getting the smallest possible code, but I'm OK with having no more than two copies of everything in the finally block. I think with the addition of the

This example is pretty compelling, but I still think I want to limit the scope of this change to not include this feature. It's probably reasonable to hold onto the idea as future work, though. In the meantime, frontends can decide for themselves whether they want code size or stronger optimization of cleanups by doing early outlining or not. The only way we can hit the quadratic growth from

> optimizing EH codepaths is not usually performance critical. >> Leaving aside the rest of the thread, I feel the need to refute this point in isolation. I've found that optimizing (usually simplifying and eliminating) exception paths ends up being *extremely* important for my workloads. Failing to optimize exception paths sufficiently tends to indirectly hurt things like inlining