Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] Exception Handling Problems"
2011 Apr 13
0
[LLVMdev] Exception Handling Problems
Pardon the basic question, but does this apply to clang, llvm-gcc, or
both?
Thanks,
-David
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Bill Wendling
Sent: Tuesday, April 12, 2011 3:05 PM
To: llvmdev List
Subject: [LLVMdev] Exception Handling Problems
Exception handling in LLVM is broken. It's as simple as that.
We
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
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 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 Dec 07
2
[LLVMdev] Inlining and exception handling in LLVM and GCC
Hi John,
On 07/12/10 01:01, John McCall wrote:
> On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote:
>> The poor interaction between exception handling and inlining in LLVM is one of
>> the main motivations for the new exception handling models proposed recently.
>> Here I give my analysis of the origin of the problem in the hope of clarifying
>> the situation.
>
>
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
2010 Dec 06
4
[LLVMdev] Inlining and exception handling in LLVM and GCC
The poor interaction between exception handling and inlining in LLVM is one of
the main motivations for the new exception handling models proposed recently.
Here I give my analysis of the origin of the problem in the hope of clarifying
the situation.
Soon after dwarf exception handling was implemented in LLVM, I noticed that some
programs would fail when compiled at -O3, for example the
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 Nov 25
3
[LLVMdev] RFC: Exception Handling Proposal II
On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote:
> On Nov 24, 2010, at 6:41 PM, John McCall wrote:
>> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,
2010 Nov 25
0
[LLVMdev] RFC: Exception Handling Proposal II
On Nov 24, 2010, at 6:41 PM, John McCall wrote:
> On Nov 24, 2010, at 5:07 PM, Bill Wendling wrote:
>
>> On Nov 24, 2010, at 11:18 AM, John McCall wrote:
>>
>>> I think my model has some nice conceptual advantages; for one, it gives you the constraint that only EH edges and dispatch instructions can lead to landing pads, which I think will simplify what EH
2010 Dec 07
0
[LLVMdev] Inlining and exception handling in LLVM and GCC
On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote:
> The poor interaction between exception handling and inlining in LLVM is one of
> the main motivations for the new exception handling models proposed recently.
> Here I give my analysis of the origin of the problem in the hope of clarifying
> the situation.
Your analysis coincides with the analysis I made when implementing EH
in clang.
2010 Dec 02
2
[LLVMdev] Alternative exception handling proposal
Hi John,
>> 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()
>>
2010 Nov 25
3
[LLVMdev] RFC: Exception Handling Proposal II
On Nov 24, 2010, at 5:07 PM, Bill Wendling wrote:
> On Nov 24, 2010, at 11:18 AM, John McCall wrote:
>
>> On Nov 24, 2010, at 5:36 AM, Bill Wendling wrote:
>>> Ah ha! I think I had a different mental model than you did. Or at least I remembered things differently from the discussion. :-) For me, there is one dispatch per region, which is why I had the region number
2010 Dec 07
0
[LLVMdev] Inlining and exception handling in LLVM and GCC
On Dec 7, 2010, at 3:38 AM, Duncan Sands wrote:
> Hi John,
>
> On 07/12/10 01:01, John McCall wrote:
>> On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote:
>>> The poor interaction between exception handling and inlining in LLVM is one of
>>> the main motivations for the new exception handling models proposed recently.
>>> Here I give my analysis of the
2010 Nov 25
0
[LLVMdev] RFC: Exception Handling Proposal II
On Nov 24, 2010, at 11:18 AM, John McCall wrote:
> On Nov 24, 2010, at 5:36 AM, Bill Wendling wrote:
>> Ah ha! I think I had a different mental model than you did. Or at least I remembered things differently from the discussion. :-) For me, there is one dispatch per region, which is why I had the region number associated with the invokes as well as the "unwind to" edge coming
2015 Jan 27
2
[LLVMdev] RFC: Native Windows C++ exception handling
I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers.
I believe
2007 Dec 09
0
[LLVMdev] Darwin vs exceptions
Hi Dale,
> #include <cstdio>
> class A {
> public:
> A() {}
> ~A() {}
> };
> void f() {
> A a;
> throw 5.0;
> }
> main() {
> try {
> f();
> } catch(...) { printf("caught\n"); }
> }
this example indeed shows the problem. Let me explain to see if we agree on what
the problem is. Suppose we don't artificially
2007 Dec 10
3
[LLVMdev] Darwin vs exceptions
On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote:
> Hi Dale,
>
>> #include <cstdio>
>> class A {
>> public:
>> A() {}
>> ~A() {}
>> };
>> void f() {
>> A a;
>> throw 5.0;
>> }
>> main() {
>> try {
>> f();
>> } catch(...) { printf("caught\n"); }
>> }
>
> this example
2010 Nov 24
2
[LLVMdev] RFC: Exception Handling Proposal II
On Nov 24, 2010, at 5:36 AM, Bill Wendling wrote:
> On Nov 24, 2010, at 4:58 AM, John McCall wrote:
>>
>>> The object 'f' is in a different cleanup area than 'b' which, in turn
>>> is in a different area than 'z'. These three regions should point to
>>> three different landing pads (or different offsets in the same landing
>>>
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