Hi Reid,
I’ve worked through a few scenarios, and I think this is converging. I’m
attaching a new example, which extends the one we’ve been working through to
handle a few more cases.
I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions
entry to be. I’ve been using it as a place to store the eh state that I’m
associating with the action, but that’s kind of circular because I’m using the
information in these tables to calculate that value. I’ll be able to do this
calculation in the MSVCEHPrepare pass before these instructions are added, so I
can put it there (it’s nice for readability), but the later pass that generates
the tables (assuming we leave that in a later pass) will need information not
represented in the action table (at least as I’ve been using it). I’m not 100%
sure that this is necessary, but it seemed like the way things ought to be.
I’ll experiment more before anything gets set in stone.
In addition to the IP-to-state table that we’ve talked about, we also need an
unwind table (which has each state, the state it transitions to when it expires
and the unwind handler, if any) and a catch handler table (which has the range
of states that can throw to the handlers, the state of the handlers and a map of
types handled to their handlers). I’ve got examples of these in the attached
example.
So I now have a firm plan for how to compute these tables from the outlined IR.
I think the algorithm you proposed for computing eh states doesn’t quite work.
In particular, if multiple catch handlers get added by the same landing pad
we’ll want to start by assuming that they have the same state. If they end up
getting popped at different times then we’ll need to update the eh state of the
one that gets popped first. Unfortunately my example doesn’t cover this case,
but I worked through it and my new algorithm (based on your but slightly
tweaked) works for that case. Also, unwind handlers get discrete states (they
happen when a transition crosses the state, but in the .xdata tables they are
represented with a single state). Catch handlers, on the other hand, do get a
range.
Anyway, here’s what I’m doing (by hand so far, I don’t have it coded yet).
1. Start with an empty stack of actions and an empty master list of eh state.
2. Visit each landing pad in succession, processing the actions at that landing
pad back to front.
3. Pop actions from the current stack that aren’t in the current landing pad’s
action table
a. If a catch is popped that had been assumed to have the same state as a
catch that isn’t being popped
its state number and all state numbers above it need to be
incremented
b. When a catch is popped, the next available eh_state is assigned to its
handler
4. As an action is pushed to the current stack, it is assigned an eh_state in
the master list
a. If the action was an unwind or if it was a cacth after an unwind, the next
available eh_state is incremented
b. If the action was a catch following a catch that was also just added, it
gets the same eh_state as the previous catch
5. When all landing pads have been handled, the remaining actions are popped and
processed as above.
The “next” state for each eh_state can also be computed during the above process
by observing the state of the action on the top of the current action stack when
the action associated with the state is popped. In the case of catch handlers,
I think the next state will always be the same as the next state of the
corresponding catch action.
So, I think it makes sense to compute the unwind and catch tables during the
MSVCEHPrepare pass, but I wasn’t sure how best to preserve the information once
it was computed. Is it reasonable to stick this in metadata?
We can keep fine tuning this if you like, but I think it’s looking solid enough
that I’m going to start revising my outlining patch to produce the results in
the attached example.
-Andy
From: Reid Kleckner [mailto:rnk at google.com]
Sent: Tuesday, January 27, 2015 1:55 PM
To: Kaylor, Andrew
Cc: Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers
Mailing List; Anton Korobeynikov; Kreitzer, David L
Subject: Re: [LLVMdev] RFC: Native Windows C++ exception handling
On Tue, Jan 27, 2015 at 12:58 PM, Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
Thanks, Reid. These are good points.
So I guess that does take us back to something more like my original proposal.
I like your suggestion of having some kind of “eh.actions” intrinsic to
represent the outlining rather than the extension to landingpad that I had
proposed. I was just working on something like that in conjunction with my
second alternative idea.
Great!
What I’d really like is to have the “eh.actions” intrinsic take a shape that
makes it really easy to construct the .xdata table directly from these calls.
As I think I mentioned in my original post, I think I have any idea for how to
reconstruct functionally correct eh states (at least for synchronous EH
purposes) from the invoke and landingpad instructions. I would like to
continue, as in my original proposal, limiting the unwind representations to
those that are unique to a given landing pad. I think with enough documentation
I can make that seem sensible.
My thinking is that the "eh.actions" list can be transformed into a
compact xdata table later, after we've done machine basic block layout.
I think the algorithm will be something like
1. Input: already laid out MachineFunction
2. Call EHStreamer::computeCallSiteTable to populate a LandingPadInfo vector
sorted by ascending PC values
4. Iterate the LandingPadInfos, comparing the action list of each landing pad
with the previous landing pad, assuming an empty action list at function start
and end.
5. Model the action list as a stack, and compute the common suffix of the
landing pad action lists
6. Each new action pushed represents a new EH state number
7. Pushing a cleanup action adds a state table entry that transitions from the
current EH state to the previous with a cleanup handler
8. Pushing a catch action adds a new unwind table entry with an open range from
the current EH state to an unknown EH state. The state after catching is... ???
9. Popping a catch action closes an open unwind table range
So, I think the action list is at least not totally crazy. =)
I’ll start working on a revised proposal. Let me know if you have any more
solid ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/dddf8797/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nested-2.ll
Type: application/octet-stream
Size: 19583 bytes
Desc: nested-2.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/dddf8797/attachment.obj>
Nice. This seems like a good starting design for some patches.
I'm not sure exactly how step 3.a works. Does it stem from step 4.b which
assigns the same eh_state to two catch handlers? It seems like these rules
would come into play in these examples:
// 'catch int' and 'catch float' have the same incoming eh_state
range
try { f(); }
catch (int) { g(); }
catch (float) { h(); }
// 'catch float' covers more than 'catch int', has different
eh_state
range, we need to do step 3.a when we reach 'invoke void @g()'
try {
try { f(); }
catch (int) { g(); }
} catch (float) { h(); }
Is that the idea?
> So, I think it makes sense to compute the unwind and catch tables during
the MSVCEHPrepare pass, but I wasn’t sure how best to preserve the
information once it was computed. Is it reasonable to stick this in
metadata?
I guess we can do the EH state assignment in the preparation pass, so long
as it's resilient to basic block reordering. A good source program to play
with would be:
extern int global;
void g();
void h();
void i();
void f() {
g();
try {
h();
if (__builtin_unlikely(global))
i();
h();
} catch (int) {
}
g();
}
The LLVM IR will preserve source order, but block placement will see the
branch hint and rearrange to:
callq g
callq h
testl global(%rip)
jne .L1
.L2:
callq h
callq g
.L1:
callq i
jmp .L2
Perhaps we can assign landing pads EH states during preparation by placing
a call to something like @llvm.eh.state there, or making it part of the
@llvm.eh.actions call? Then the ip2state table will assign the .L1 block
the same state as the range over the h() calls.
On Wed, Jan 28, 2015 at 4:49 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>
wrote:
> Hi Reid,
>
>
>
> I’ve worked through a few scenarios, and I think this is converging. I’m
> attaching a new example, which extends the one we’ve been working through
> to handle a few more cases.
>
>
>
> I wasn’t sure what you intended the first i32 argument in an
> llvm.eh.actions entry to be. I’ve been using it as a place to store the eh
> state that I’m associating with the action, but that’s kind of circular
> because I’m using the information in these tables to calculate that value.
> I’ll be able to do this calculation in the MSVCEHPrepare pass before these
> instructions are added, so I can put it there (it’s nice for readability),
> but the later pass that generates the tables (assuming we leave that in a
> later pass) will need information not represented in the action table (at
> least as I’ve been using it). I’m not 100% sure that this is necessary,
> but it seemed like the way things ought to be. I’ll experiment more before
> anything gets set in stone.
>
>
>
> In addition to the IP-to-state table that we’ve talked about, we also need
> an unwind table (which has each state, the state it transitions to when it
> expires and the unwind handler, if any) and a catch handler table (which
> has the range of states that can throw to the handlers, the state of the
> handlers and a map of types handled to their handlers). I’ve got examples
> of these in the attached example.
>
>
>
> So I now have a firm plan for how to compute these tables from the
> outlined IR.
>
>
>
> I think the algorithm you proposed for computing eh states doesn’t quite
> work. In particular, if multiple catch handlers get added by the same
> landing pad we’ll want to start by assuming that they have the same state.
> If they end up getting popped at different times then we’ll need to update
> the eh state of the one that gets popped first. Unfortunately my example
> doesn’t cover this case, but I worked through it and my new algorithm
> (based on your but slightly tweaked) works for that case. Also, unwind
> handlers get discrete states (they happen when a transition crosses the
> state, but in the .xdata tables they are represented with a single state).
> Catch handlers, on the other hand, do get a range.
>
>
>
> Anyway, here’s what I’m doing (by hand so far, I don’t have it coded yet).
>
>
>
> 1. Start with an empty stack of actions and an empty master list of eh
> state.
>
> 2. Visit each landing pad in succession, processing the actions at that
> landing pad back to front.
>
> 3. Pop actions from the current stack that aren’t in the current landing
> pad’s action table
>
> a. If a catch is popped that had been assumed to have the same state as
> a catch that isn’t being popped
>
> its state number and all state numbers above it need to be
> incremented
>
> b. When a catch is popped, the next available eh_state is assigned to
> its handler
>
> 4. As an action is pushed to the current stack, it is assigned an eh_state
> in the master list
>
> a. If the action was an unwind or if it was a cacth after an unwind,
> the next available eh_state is incremented
>
> b. If the action was a catch following a catch that was also just
> added, it gets the same eh_state as the previous catch
>
> 5. When all landing pads have been handled, the remaining actions are
> popped and processed as above.
>
>
>
> The “next” state for each eh_state can also be computed during the above
> process by observing the state of the action on the top of the current
> action stack when the action associated with the state is popped. In the
> case of catch handlers, I think the next state will always be the same as
> the next state of the corresponding catch action.
>
>
>
> So, I think it makes sense to compute the unwind and catch tables during
> the MSVCEHPrepare pass, but I wasn’t sure how best to preserve the
> information once it was computed. Is it reasonable to stick this in
> metadata?
>
>
>
> We can keep fine tuning this if you like, but I think it’s looking solid
> enough that I’m going to start revising my outlining patch to produce the
> results in the attached example.
>
>
>
> -Andy
>
>
>
>
>
> *From:* Reid Kleckner [mailto:rnk at google.com]
> *Sent:* Tuesday, January 27, 2015 1:55 PM
> *To:* Kaylor, Andrew
> *Cc:* Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers
> Mailing List; Anton Korobeynikov; Kreitzer, David L
> *Subject:* Re: [LLVMdev] RFC: Native Windows C++ exception handling
>
>
>
> On Tue, Jan 27, 2015 at 12:58 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>
> wrote:
>
> Thanks, Reid. These are good points.
>
>
>
> So I guess that does take us back to something more like my original
> proposal.
>
>
>
> I like your suggestion of having some kind of “eh.actions” intrinsic to
> represent the outlining rather than the extension to landingpad that I had
> proposed. I was just working on something like that in conjunction with my
> second alternative idea.
>
>
>
> Great!
>
>
>
> What I’d really like is to have the “eh.actions” intrinsic take a shape
> that makes it really easy to construct the .xdata table directly from these
> calls. As I think I mentioned in my original post, I think I have any idea
> for how to reconstruct functionally correct eh states (at least for
> synchronous EH purposes) from the invoke and landingpad instructions. I
> would like to continue, as in my original proposal, limiting the unwind
> representations to those that are unique to a given landing pad. I think
> with enough documentation I can make that seem sensible.
>
>
>
> My thinking is that the "eh.actions" list can be transformed into
a
> compact xdata table later, after we've done machine basic block layout.
>
>
>
> I think the algorithm will be something like
>
>
>
> 1. Input: already laid out MachineFunction
>
> 2. Call EHStreamer::computeCallSiteTable to populate a LandingPadInfo
> vector sorted by ascending PC values
>
> 4. Iterate the LandingPadInfos, comparing the action list of each landing
> pad with the previous landing pad, assuming an empty action list at
> function start and end.
>
> 5. Model the action list as a stack, and compute the common suffix of the
> landing pad action lists
>
> 6. Each new action pushed represents a new EH state number
>
> 7. Pushing a cleanup action adds a state table entry that transitions from
> the current EH state to the previous with a cleanup handler
>
> 8. Pushing a catch action adds a new unwind table entry with an open range
> from the current EH state to an unknown EH state. The state after catching
> is... ???
>
> 9. Popping a catch action closes an open unwind table range
>
>
>
> So, I think the action list is at least not totally crazy. =)
>
>
>
> I’ll start working on a revised proposal. Let me know if you have any
> more solid ideas.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/9f755401/attachment.html>
> I'm not sure exactly how step 3.a works. Does it stem from step 4.b which assigns the same eh_state to two catch handlers? It seems like these rules would come into play in these examples: > … > Is that the idea?Yes. That’s the case I’m trying to handle with the 3a fixup. In the final implementation I hope to come up with something cleaner (maybe looking ahead when the state is assigned in the first place), but the result will be the same.> I guess we can do the EH state assignment in the preparation pass, so long as it's resilient to basic block reordering.I think the EH state assignment (that is, the actual numbering) depends on control flow rather than physical block ordering, so I expect that the prepare pass will be the right place to do it. Then, as you say, the IP to State table will be constructed later. I guess we can work out the details while reviewing patches, but I’m happy to use some combination of intrinsics as you suggest. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/86dcc6ae/attachment.html>
Joseph Tremoulet
2015-Feb-11 02:21 UTC
[LLVMdev] RFC: Native Windows C++ exception handling
Hi,
Sorry if I'm late to the party. I'm curious whether you need to be
concerned about code being moved into the landing pad area with this approach
(i.e. whether "real code" might wind up in the eh.actions call's
block which [if I'm following correctly] won't actually get executed at
runtime).
For example, given something like
int foo (int a, int b) {
int x;
try {
x = a + b;
maybe_throw();
return 0;
} catch (int) {
return x;
} catch (float) {
return x + 1;
}
}
Do you need to worry that something like partial deadcode elimination could want
to move the definition of x down into the landing pad code (but not all the way
down into the catch handlers)?
Or conversely, given something like
int foo(int a, int b) {
try {
maybe_throw();
return 0;
} catch (int) {
return a + b;
} catch (float) {
return (a + b) + 1;
}
}
Do you need to worry that something like very busy expressions could want to
hoist the "a + b" computation up into the landing pad code (but not
all the way up into the try block)?
Should those sorts of code motion be legal? If not, what's preventing them,
and if so, how will the moved code be executed at runtime?
Thanks
-Joseph
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Kaylor, Andrew
Sent: Wednesday, January 28, 2015 7:49 PM
To: Reid Kleckner
Cc: Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers
Mailing List
Subject: Re: [LLVMdev] RFC: Native Windows C++ exception handling
Hi Reid,
I’ve worked through a few scenarios, and I think this is converging. I’m
attaching a new example, which extends the one we’ve been working through to
handle a few more cases.
I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions
entry to be. I’ve been using it as a place to store the eh state that I’m
associating with the action, but that’s kind of circular because I’m using the
information in these tables to calculate that value. I’ll be able to do this
calculation in the MSVCEHPrepare pass before these instructions are added, so I
can put it there (it’s nice for readability), but the later pass that generates
the tables (assuming we leave that in a later pass) will need information not
represented in the action table (at least as I’ve been using it). I’m not 100%
sure that this is necessary, but it seemed like the way things ought to be.
I’ll experiment more before anything gets set in stone.
In addition to the IP-to-state table that we’ve talked about, we also need an
unwind table (which has each state, the state it transitions to when it expires
and the unwind handler, if any) and a catch handler table (which has the range
of states that can throw to the handlers, the state of the handlers and a map of
types handled to their handlers). I’ve got examples of these in the attached
example.
So I now have a firm plan for how to compute these tables from the outlined IR.
I think the algorithm you proposed for computing eh states doesn’t quite work.
In particular, if multiple catch handlers get added by the same landing pad
we’ll want to start by assuming that they have the same state. If they end up
getting popped at different times then we’ll need to update the eh state of the
one that gets popped first. Unfortunately my example doesn’t cover this case,
but I worked through it and my new algorithm (based on your but slightly
tweaked) works for that case. Also, unwind handlers get discrete states (they
happen when a transition crosses the state, but in the .xdata tables they are
represented with a single state). Catch handlers, on the other hand, do get a
range.
Anyway, here’s what I’m doing (by hand so far, I don’t have it coded yet).
1. Start with an empty stack of actions and an empty master list of eh state.
2. Visit each landing pad in succession, processing the actions at that landing
pad back to front.
3. Pop actions from the current stack that aren’t in the current landing pad’s
action table
a. If a catch is popped that had been assumed to have the same state as a
catch that isn’t being popped
its state number and all state numbers above it need to be
incremented
b. When a catch is popped, the next available eh_state is assigned to its
handler
4. As an action is pushed to the current stack, it is assigned an eh_state in
the master list
a. If the action was an unwind or if it was a cacth after an unwind, the next
available eh_state is incremented
b. If the action was a catch following a catch that was also just added, it
gets the same eh_state as the previous catch
5. When all landing pads have been handled, the remaining actions are popped and
processed as above.
The “next” state for each eh_state can also be computed during the above process
by observing the state of the action on the top of the current action stack when
the action associated with the state is popped. In the case of catch handlers,
I think the next state will always be the same as the next state of the
corresponding catch action.
So, I think it makes sense to compute the unwind and catch tables during the
MSVCEHPrepare pass, but I wasn’t sure how best to preserve the information once
it was computed. Is it reasonable to stick this in metadata?
We can keep fine tuning this if you like, but I think it’s looking solid enough
that I’m going to start revising my outlining patch to produce the results in
the attached example.
-Andy
From: Reid Kleckner [mailto:rnk at google.com]
Sent: Tuesday, January 27, 2015 1:55 PM
To: Kaylor, Andrew
Cc: Bataev, Alexey; Reid Kleckner (reid at kleckner.net<mailto:reid at
kleckner.net>); LLVM Developers Mailing List; Anton Korobeynikov; Kreitzer,
David L
Subject: Re: [LLVMdev] RFC: Native Windows C++ exception handling
On Tue, Jan 27, 2015 at 12:58 PM, Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
Thanks, Reid. These are good points.
So I guess that does take us back to something more like my original proposal.
I like your suggestion of having some kind of “eh.actions” intrinsic to
represent the outlining rather than the extension to landingpad that I had
proposed. I was just working on something like that in conjunction with my
second alternative idea.
Great!
What I’d really like is to have the “eh.actions” intrinsic take a shape that
makes it really easy to construct the .xdata table directly from these calls.
As I think I mentioned in my original post, I think I have any idea for how to
reconstruct functionally correct eh states (at least for synchronous EH
purposes) from the invoke and landingpad instructions. I would like to
continue, as in my original proposal, limiting the unwind representations to
those that are unique to a given landing pad. I think with enough documentation
I can make that seem sensible.
My thinking is that the "eh.actions" list can be transformed into a
compact xdata table later, after we've done machine basic block layout.
I think the algorithm will be something like
1. Input: already laid out MachineFunction
2. Call EHStreamer::computeCallSiteTable to populate a LandingPadInfo vector
sorted by ascending PC values
4. Iterate the LandingPadInfos, comparing the action list of each landing pad
with the previous landing pad, assuming an empty action list at function start
and end.
5. Model the action list as a stack, and compute the common suffix of the
landing pad action lists
6. Each new action pushed represents a new EH state number
7. Pushing a cleanup action adds a state table entry that transitions from the
current EH state to the previous with a cleanup handler
8. Pushing a catch action adds a new unwind table entry with an open range from
the current EH state to an unknown EH state. The state after catching is... ???
9. Popping a catch action closes an open unwind table range
So, I think the action list is at least not totally crazy. =)
I’ll start working on a revised proposal. Let me know if you have any more
solid ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150211/4f8e1667/attachment.html>
These are exactly the sorts of code transformations we want to allow by delaying the outlining until later. By keeping such code inlined in the parent function until after optimization, we enable a lot of core optimizations like SROA. For example, we should be able to completely eliminate wrappers like unique_ptr that would otherwise stay around due to the pointer escaped to the destructor call that gets executed on exception. On Tue, Feb 10, 2015 at 6:21 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote:> Hi, > > > > Sorry if I'm late to the party. I'm curious whether you need to be > concerned about code being moved into the landing pad area with this > approach (i.e. whether "real code" might wind up in the eh.actions call's > block which [if I'm following correctly] won't actually get executed at > runtime). > > > > For example, given something like > > > > int foo (int a, int b) { > > int x; > > try { > > x = a + b; > > maybe_throw(); > > return 0; > > } catch (int) { > > return x; > > } catch (float) { > > return x + 1; > > } > > } > > > > Do you need to worry that something like partial deadcode elimination > could want to move the definition of x down into the landing pad code (but > not all the way down into the catch handlers)? > > > > Or conversely, given something like > > > > int foo(int a, int b) { > > try { > > maybe_throw(); > > return 0; > > } catch (int) { > > return a + b; > > } catch (float) { > > return (a + b) + 1; > > } > > } > > > > Do you need to worry that something like very busy expressions could want > to hoist the "a + b" computation up into the landing pad code (but not all > the way up into the try block)? > > > > Should those sorts of code motion be legal? If not, what's preventing > them, and if so, how will the moved code be executed at runtime? > > > > Thanks > > -Joseph > > > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Kaylor, Andrew > *Sent:* Wednesday, January 28, 2015 7:49 PM > *To:* Reid Kleckner > *Cc:* Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers > Mailing List > *Subject:* Re: [LLVMdev] RFC: Native Windows C++ exception handling > > > > Hi Reid, > > > > I’ve worked through a few scenarios, and I think this is converging. I’m > attaching a new example, which extends the one we’ve been working through > to handle a few more cases. > > > > I wasn’t sure what you intended the first i32 argument in an > llvm.eh.actions entry to be. I’ve been using it as a place to store the eh > state that I’m associating with the action, but that’s kind of circular > because I’m using the information in these tables to calculate that value. > I’ll be able to do this calculation in the MSVCEHPrepare pass before these > instructions are added, so I can put it there (it’s nice for readability), > but the later pass that generates the tables (assuming we leave that in a > later pass) will need information not represented in the action table (at > least as I’ve been using it). I’m not 100% sure that this is necessary, > but it seemed like the way things ought to be. I’ll experiment more before > anything gets set in stone. > > > > In addition to the IP-to-state table that we’ve talked about, we also need > an unwind table (which has each state, the state it transitions to when it > expires and the unwind handler, if any) and a catch handler table (which > has the range of states that can throw to the handlers, the state of the > handlers and a map of types handled to their handlers). I’ve got examples > of these in the attached example. > > > > So I now have a firm plan for how to compute these tables from the > outlined IR. > > > > I think the algorithm you proposed for computing eh states doesn’t quite > work. In particular, if multiple catch handlers get added by the same > landing pad we’ll want to start by assuming that they have the same state. > If they end up getting popped at different times then we’ll need to update > the eh state of the one that gets popped first. Unfortunately my example > doesn’t cover this case, but I worked through it and my new algorithm > (based on your but slightly tweaked) works for that case. Also, unwind > handlers get discrete states (they happen when a transition crosses the > state, but in the .xdata tables they are represented with a single state). > Catch handlers, on the other hand, do get a range. > > > > Anyway, here’s what I’m doing (by hand so far, I don’t have it coded yet). > > > > 1. Start with an empty stack of actions and an empty master list of eh > state. > > 2. Visit each landing pad in succession, processing the actions at that > landing pad back to front. > > 3. Pop actions from the current stack that aren’t in the current landing > pad’s action table > > a. If a catch is popped that had been assumed to have the same state as > a catch that isn’t being popped > > its state number and all state numbers above it need to be > incremented > > b. When a catch is popped, the next available eh_state is assigned to > its handler > > 4. As an action is pushed to the current stack, it is assigned an eh_state > in the master list > > a. If the action was an unwind or if it was a cacth after an unwind, > the next available eh_state is incremented > > b. If the action was a catch following a catch that was also just > added, it gets the same eh_state as the previous catch > > 5. When all landing pads have been handled, the remaining actions are > popped and processed as above. > > > > The “next” state for each eh_state can also be computed during the above > process by observing the state of the action on the top of the current > action stack when the action associated with the state is popped. In the > case of catch handlers, I think the next state will always be the same as > the next state of the corresponding catch action. > > > > So, I think it makes sense to compute the unwind and catch tables during > the MSVCEHPrepare pass, but I wasn’t sure how best to preserve the > information once it was computed. Is it reasonable to stick this in > metadata? > > > > We can keep fine tuning this if you like, but I think it’s looking solid > enough that I’m going to start revising my outlining patch to produce the > results in the attached example. > > > > -Andy > > > > > > *From:* Reid Kleckner [mailto:rnk at google.com <rnk at google.com>] > *Sent:* Tuesday, January 27, 2015 1:55 PM > *To:* Kaylor, Andrew > *Cc:* Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers > Mailing List; Anton Korobeynikov; Kreitzer, David L > *Subject:* Re: [LLVMdev] RFC: Native Windows C++ exception handling > > > > On Tue, Jan 27, 2015 at 12:58 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote: > > Thanks, Reid. These are good points. > > > > So I guess that does take us back to something more like my original > proposal. > > > > I like your suggestion of having some kind of “eh.actions” intrinsic to > represent the outlining rather than the extension to landingpad that I had > proposed. I was just working on something like that in conjunction with my > second alternative idea. > > > > Great! > > > > What I’d really like is to have the “eh.actions” intrinsic take a shape > that makes it really easy to construct the .xdata table directly from these > calls. As I think I mentioned in my original post, I think I have any idea > for how to reconstruct functionally correct eh states (at least for > synchronous EH purposes) from the invoke and landingpad instructions. I > would like to continue, as in my original proposal, limiting the unwind > representations to those that are unique to a given landing pad. I think > with enough documentation I can make that seem sensible. > > > > My thinking is that the "eh.actions" list can be transformed into a > compact xdata table later, after we've done machine basic block layout. > > > > I think the algorithm will be something like > > > > 1. Input: already laid out MachineFunction > > 2. Call EHStreamer::computeCallSiteTable to populate a LandingPadInfo > vector sorted by ascending PC values > > 4. Iterate the LandingPadInfos, comparing the action list of each landing > pad with the previous landing pad, assuming an empty action list at > function start and end. > > 5. Model the action list as a stack, and compute the common suffix of the > landing pad action lists > > 6. Each new action pushed represents a new EH state number > > 7. Pushing a cleanup action adds a state table entry that transitions from > the current EH state to the previous with a cleanup handler > > 8. Pushing a catch action adds a new unwind table entry with an open range > from the current EH state to an unknown EH state. The state after catching > is... ??? > > 9. Popping a catch action closes an open unwind table range > > > > So, I think the action list is at least not totally crazy. =) > > > > I’ll start working on a revised proposal. Let me know if you have any > more solid ideas. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150211/513842e5/attachment.html>
Possibly Parallel Threads
- [LLVMdev] RFC: Native Windows C++ exception handling
- [LLVMdev] RFC: Native Windows C++ exception handling
- [LLVMdev] RFC: Native Windows C++ exception handling
- [LLVMdev] RFC: Native Windows C++ exception handling
- [LLVMdev] RFC: Native Windows C++ exception handling