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