search for: cleanupblocks

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

...om] > *Sent:* Tuesday, May 19, 2015 7:26 PM > > *To:* Joseph Tremoulet > *Cc:* LLVM Developers Mailing List; Bill Wendling; Nick Lewycky; Kaylor, > Andrew > *Subject:* Re: [LLVMdev] RFC: New EH representation for MSVC compatibility > > > > 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 o...

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

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

On Wed, Jul 1, 2015 at 2:10 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > I'd be interested in an updated summary as well, especially any thoughts > you have on when the various pieces might come online and where extra hands > could be helpful; we're eager to build our EH support in LLILC on top of > this. > A preliminary step was

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,

...hblock ends the lifetime of the exception object, so I'd say that's a "writes escaped memory" constraint. That said, a resume after a cleanupblock doesn't, but I'm not sure it's worth having this kind of fine-grained analysis. I'm OK teaching SimplifyCFG to combine cleanupblocks and leaving it at that. > - Does LLVM already have other examples of terminators that are glued to > the top of their basic blocks, or will these be the first? I ask because > it's a somewhat nonstandard thing (a block in the CFG that can't have > instructions added to it) th...

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.