search for: cleanupblock

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

...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 from label %cleanup to label %return ; unwind label would go here if there were an action The endcleanup instruction would use 'to' and 'unwind' label operands to mirror the structure of an invo...

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

...lls were inside the catch scope. resume has two roles: moving to the next EH action after a cleanup, and transitioning from the catch block back to normal control flow. Some of my coworkers said it should be split into two instructions for each purpose, and I could go either way. > > %val = cleanupblock <valty> unwind label %nextaction > > > > Why isn’t this a terminator? It seems like it performs the same sort of > role as catchblock, except presumably it is always entered. I suppose > that’s probably the answer to my question, but it strikes me as an > ambiguity in t...

...be helpful; we're eager 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...

...atch blocks of a try. Invokes that are reached after a catchblock without following any unwind edges must transitively unwind to the first catchend block that the catchblock unwinds to. Executing such an invoke that does not transitively unwind to the correct catchend block has undefined behavior. cleanupblock -------------------- %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. terminateb...

...hat does not > transitively unwind to the correct catchend block has undefined behavior" > rule? > Yes, crossing a resume from a catchblock 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 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.