Displaying 3 results from an estimated 3 matches for "_z1cv".
Did you mean:
_z1bv
2010 Dec 02
2
[LLVMdev] Alternative exception handling proposal
...; preds = %"<L1>"
%D.2112_2 = tail call i8* @__cxa_begin_catch(i8* %exc_ptr) nounwind
tail call void @__cxa_end_catch() nounwind
ret void
return: ; preds = %entry
ret void
}
define void @_Z1cv() {
entry:
invoke void @_Z1bv()
to label %return unwind label %"<L1>" personality
@__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIf
"<L1>": ; preds = %entry
%exc_ptr = tail call i...
2010 Dec 01
0
[LLVMdev] Alternative exception handling proposal
On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote:
> Inlining
> --------
>
> Many a plausible seeming exception handling scheme has fallen by the way-side
> because it interacts poorly with inlining.
>
> Here is how inlining would work with this scheme. It's pretty close to how
> it works right now. Suppose you have
>
> invoke void @foo()
> to
2010 Dec 01
8
[LLVMdev] Alternative exception handling proposal
Here is an alternative proposal to Bill's. It is closer to what we already
have (which can be seen as a good or a bad thing!), and is also closer to
what gcc does. It is more incremental than Bill's and introduces fewer
new concepts.
Executive summary
-----------------
Remove the personality and list of catches out of eh.selector and stick them
directly on invoke instructions.
The