similar to: [LLVMdev] LLVMdev Digest, Vol 77, Issue 37

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

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

On Nov 24, 2010, at 2:59 AM, Renato Golin wrote: > Hi Bill, > > First, I like the idea of being more expressive in IR, since the old > exception handling style didn't quite express exception handling, but > alternate paths (resume/unwind). That made DwarfException.cpp a big > hack. ;) > > It also makes the front-end engineer's life a lot easier, since there >

Hi Bill, First, I like the idea of being more expressive in IR, since the old exception handling style didn't quite express exception handling, but alternate paths (resume/unwind). That made DwarfException.cpp a big hack. ;) It also makes the front-end engineer's life a lot easier, since there is less need to keep a long list of global state for all current landing pads, clean up areas,

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

Hello all, A few years ago, I added the inalloca feature to LLVM IR so that Clang could be C++ ABI compatible with MSVC on 32-bit x86. The feature works, but there is room for improvement. I recently took the time to write up a design using token values that will hopefully be better named and easier to work with and around. For the technical details of the proposal, I've written up the RFC

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

responses to the Exception Handling Proposal are "all over the map", including at least.... 1. what are the semantics of the various high level languages, and how are these constructs to be lowered into an IR 2. what should the IR be 3. what should the final output code format and layout be, and to what extent can/should this be compatible with any existing runtime environments

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

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

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

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

Hi Bill, >>> Yeah. The logic will need tweaking for sure. I'm also concerned about the >>> _Unwind_resume() call. GCC emits a call site region for it in the exception >>> table. We...kind of do that. It looks like it's being included in one of the >>> "this is a region which isn't in a try-catch block, but it has a call in it, >>> so

Hi, My data has column names which has ` character. For example , *> names(dataframe) [1] "`region" "farmsize`" "farmincome" "maincrop" "claimvalue"* If i use these objects in my function, the following error is thrown. *lmm<-lm(``region`~farmincome) Error: attempt to use zero-length variable name* Is there a way, say an escape

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

On Thu, Sep 17, 2009 at 3:40 AM, Duncan Sands <duncan.sands at math.u-psud.fr> wrote: > Hi Bill, > >> Yeah. The logic will need tweaking for sure. I'm also concerned about the >> _Unwind_resume() call. GCC emits a call site region for it in the exception >> table. We...kind of do that. It looks like it's being included in one of the >> "this is a

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

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

On Nov 28, 2010, at 1:57 PM, Bill Wendling wrote: > On Nov 28, 2010, at 2:59 AM, John McCall wrote: > >> On Nov 28, 2010, at 2:20 AM, Bill Wendling wrote: >> >>> On Nov 27, 2010, at 4:57 PM, John McCall wrote: >>> >>>> On Nov 25, 2010, at 3:03 AM, Duncan Sands wrote: >>>>> I'm pointing out that if the invoke instruction

Hi Bill, > Yeah. The logic will need tweaking for sure. I'm also concerned about > the _Unwind_resume() call. GCC emits a call site region for it in the > exception table. We...kind of do that. It looks like it's being included > in one of the "this is a region which isn't in a try-catch block, but it > has a call in it, so lets add it to the exception