search for: catchendblock

Displaying 6 results from an estimated 6 matches for "catchendblock".

2015 May 18
4
[LLVMdev] New EH representation for MSVC compatibility
...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 there to support figuring out which calls 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 purpos...
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...#39;resume', other candidate names 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 see...
2015 May 15
8
[LLVMdev] RFC: New EH representation for MSVC compatibility
...or, no instructions can be inserted into a catchblock. The MSVC personality function requires more than just a pointer to RTTI data, so a variable list of operands is accepted. For an Itanium personality, only one RTTI operand is needed. The ‘unwind’ label of a catchblock must point to a catchend. catchendblock ---------------- catchend unwind label %nextaction The catchend is a terminator that unconditionally unwinds to the next action. It is merely a placeholder to help reconstruct which invokes were part of the catch blocks of a try. Invokes that are reached after a catchblock without following any u...
2015 May 18
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
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: > > >
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...#39;resume', other candidate names 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 see...
2015 May 20
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...#39;resume', other candidate names 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 see...