search for: catchblock

...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" bit in the EH info. There's a similar optimization we can do for Itanium that we miss today. > 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. > > > > I’m not sure I understand this correctly. In particular, I’m confused > about the roles of resume and catchend. > catchendblock is really the...

...EH personalities that produce no value resume void Now resume takes an optional label operand which is the next EH action to run. The label must point to a block starting with an EH action. The various EH action blocks impose personality-specific rules about what the targets of the resume can be. catchblock --------------- %val = catchblock <valty> [i8* @typeid.int, i32 7, i32* %e.addr] to label %catch.int unwind label %nextaction The catchblock is a terminator that conditionally selects which block to execute based on the opaque operands interpreted by the personality function. If the exc...

...liminary 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 optimizations to ensure that they do not miscompile in the face of our...

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

...ing that > code motion optimizations are expected to check for explicitly to avoid > introducing UB per the "Executing such an invoke [or call] that 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 cleanu...

...s include > 'unwind' and 'continue', and I'd like more ideas > > The first thing that comes to mind is 'endatch/exitcatch', but to use that > you'd need to rename other things since it would be confusing vis-à-vis > catchendblock and lack symmetry with catchblock that isn't prefixed with > begin/enter. > > You could consider 'filter' (or 'filterblock') for 'catchblock', since > conceptually it plays the role of a filter (typically one which consults > type information; I've seen such things called "typetes...

...s include > 'unwind' and 'continue', and I'd like more ideas > > The first thing that comes to mind is 'endatch/exitcatch', but to use that > you'd need to rename other things since it would be confusing vis-à-vis > catchendblock and lack symmetry with catchblock that isn't prefixed with > begin/enter. > > You could consider 'filter' (or 'filterblock') for 'catchblock', since > conceptually it plays the role of a filter (typically one which consults > type information; I've seen such things called "typetes...

...s include > 'unwind' and 'continue', and I'd like more ideas > > The first thing that comes to mind is 'endatch/exitcatch', but to use that > you'd need to rename other things since it would be confusing vis-à-vis > catchendblock and lack symmetry with catchblock that isn't prefixed with > begin/enter. > > You could consider 'filter' (or 'filterblock') for 'catchblock', since > conceptually it plays the role of a filter (typically one which consults > type information; I've seen such things called "typetes...

> 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