Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] RFC: Exception Handling Proposal Revised"
2010 Dec 07
0
[LLVMdev] RFC: Exception Handling Proposal Revised
Hi Bill, there are a couple of things I didn't understand about your proposal,
for example how it interacts with inlining, whether it is feasible to do the
"turn invoke-of-Unwind_Resume into a branch" optimization and also whether in
"resumedest" you still plan to use _Unwind_Resume to continue unwinding up the
stack. Could you please show what the LLVM IR would look like
2010 Dec 01
0
[LLVMdev] RFC: Exception Handling Proposal Revised
Hi Bill, this proposal seems strangely complicated. I don't see the advantage
of the dispatch instruction over just attaching the information to each invoke.
Right now you have
invoke void @_Z3foov()
to label %invcont unwind label %catch.handlers
catch.handlers: landingpad
dispatch resume to label %...
catches [
%struct.__fundamental_type_info_pseudo* @_ZTIi, label
2010 Dec 01
2
[LLVMdev] RFC: Exception Handling Proposal Revised
On Dec 1, 2010, at 10:20 AM, Duncan Sands wrote:
> Hi Bill, this proposal seems strangely complicated. I don't see the advantage
> of the dispatch instruction over just attaching the information to each invoke.
> Right now you have
>
> invoke void @_Z3foov()
> to label %invcont unwind label %catch.handlers
>
> catch.handlers: landingpad
> dispatch resume
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
2010 Dec 01
0
[LLVMdev] Alternative exception handling proposal
On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote:
> Executive summary
> -----------------
>
> Remove the personality and list of catches out of eh.selector and stick them
> directly on invoke instructions.
>
> The invoke instruction
> ----------------------
>
> The invoke instruction is modified by adding extra catch info to it:
>
> <result> = invoke
2009 May 12
1
[LLVMdev] How distinguish Catch all llvm-IR from other catch type ?
Hi,
catch_all.cpp:
1 int main()
2 {
3 try {
4 throw 34;
5 }
6 catch (...) {}
7 }
llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll:
1 ; ModuleID = 'catch_all.cpp'
2 target datalayout =
2010 Dec 02
3
[LLVMdev] Alternative exception handling proposal
Hi Bill,
> This is similar to my first proposal.
yup, I still consider your first proposal to have been basically sound.
But it also suffers from a major problem,
> which stopped that proposal dead in its tracks. Namely, you have information in
> one place which needs to be shared in two different, but possibly disjoint,
> places: the type, filters, and personality information. In
2010 Nov 24
5
[LLVMdev] RFC: Exception Handling Proposal II
Hi everyone!
I've been silently working on the previous exception handling proposal I published last year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-November/027311.html). However, there were some major deficiencies in it.
After discussing this further with Jim Grosbach and John McCall, we've come up with another proposal. As you can see, it incorporates the idea of
2011 Jul 23
14
[LLVMdev] RFC: Exception Handling Rewrite
What? Yet another EH proposal?! This one is different from the others in that
I'm planning to start implementing this shortly. But I want your feedback! I've
all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others.
Now is your turn!
Please read this proposal and send me your comments, suggestions, and concerns.
-bw
2009 Mar 26
2
[LLVMdev] how to get the InvodInst 's Operand Name?
Hi Duncan,
>>are you trying to get the name "@_ZTIi" or "@__cxa_throw"?
yes! i want get the name @_ZTi or @__cxa_throw,
the latter @__cxa_throw i can get it throw value->getName(), but the
@_ZTi it did n't has name!
zhangzw
thanks
2009/3/26 Duncan Sands <baldrick at free.fr>:
> Hi zhangzw,
>
>> invoke void @__cxa_throw(i8* %7, i8*
2010 Dec 02
0
[LLVMdev] Alternative exception handling proposal
On Dec 2, 2010, at 2:21 AM, Duncan Sands wrote:
> Hi Bill,
>
>> This is similar to my first proposal.
>
> yup, I still consider your first proposal to have been basically sound.
>
> But it also suffers from a major problem,
>> which stopped that proposal dead in its tracks. Namely, you have information in
>> one place which needs to be shared in two
2009 Mar 26
2
[LLVMdev] how to get the InvodInst 's Operand Name?
HI all,
here is a llvm IR :
invoke void @__cxa_throw(i8* %7, i8* bitcast
(%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)*
null)
noreturn to label %invcont unwind label %lpad
say I want to get the Invoke's Operand's name, I use
getOperand(i)->getName(), it can work for that the Operand hasname,
but some Operand hasn't name,
So, My problem is how
2009 Mar 26
0
[LLVMdev] how to get the InvodInst 's Operand Name?
Hi zhangzw,
>> invoke void @__cxa_throw(i8* %7, i8* bitcast
>> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)*
>> null)
>> noreturn to label %invcont unwind label %lpad
>
> >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"?
>
> yes! i want get the name @_ZTi or @__cxa_throw,
> the latter
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
2011 May 17
4
[LLVMdev] Exception Handling Proposal - Second round
Hi all,
Following John's, Duncan's and Bill's proposals about exception
handling, I thought I'd summarise what has been discussed so far.
** The problems we're trying to solve are:
P1. Different languages have different EH concepts and IR needs to be
agnostic (as possible) about that
P2. Inlining and optimisations (currently) destroy the EH semantics
and produce code that
2009 Nov 18
11
[LLVMdev] RFC: New Exception Handling Proposal
I've been looking into a new way to implement exception handling in
LLVM. The current model has many disadvantages, in my opinion. I try
to address them with this proposal. I also try to make exception
handling much more understandable to the normal human reader. :-) Any
new proposal will need to address all present and future languages'
exception handling methodologies. I
2010 Dec 01
0
[LLVMdev] RFC: Exception Handling Proposal Revised
Hi Bill,
>> Why not combine this into:
>>
>> invoke void @_Z3foov()
>> to label %invcont unwind resume to label %...
>> catches [
>> %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int
>> %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str
>> ]
>> catchall [i8* null, label % ch.ca <http://ch.ca>]
>>
>> ?
2009 Apr 28
3
[LLVMdev] how to resolve llvm exception IR?
here are the cpp file:
$ cat -n eh1.catch.cpp
1 #include <iostream>
2
3 int main()
4 {
5 try {
6 throw 78;
7 }
8 catch (int){
9
10 std::cout << "at catch\n";
11
12 }
13 }
LLVM-IR:
$ llvm-g++ -S -emit-llvm eh1.catch.cpp -o eh1.catch.ll
...
46 define i32 @main() {
2009 Mar 26
0
[LLVMdev] how to get the InvodInst 's Operand Name?
Hi zhangzw,
> invoke void @__cxa_throw(i8* %7, i8* bitcast
> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)*
> null)
> noreturn to label %invcont unwind label %lpad
>
> say I want to get the Invoke's Operand's name
are you trying to get the name "@_ZTIi" or "@__cxa_throw"?
Ciao,
Duncan.
2007 Dec 09
3
[LLVMdev] Darwin vs exceptions
(Mail system seems to have eaten this, sorry if it's a repeat)
On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote:
> Hi Dale,
>
>> - Why was C++ claiming that every selector has a catch-all handler?
>
> this is easy: because the semantics of invoke require it. Yes,
> really.
> If unwinding reaches an invoke then control is required to jump to the
> unwind basic