similar to: [LLVMdev] Exception Handling Tables Question

Hi Bill, > Right now we generate call sites for all of the code in a function, > even for code that cannot (or at least shouldn't) throw an exception. ... > (assume it's all been inlined), the EH handling table for "main" goes > from Leh_func_begin1 to Leh_func_end1, marking off each region whether > it can throw or not. From my reading of the Exception

Hi Bill, > The reason to ask this is that >> it could make the EH tables smaller and less cluttered if we elide >> those areas which we know don't throw (the functions called are marked >> 'nounwind', etc.). > > Sure, that's what the SawPotentiallyThrowing boolean is for. It is > currently set for any call, but in fact needn't be set for

Hi, I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. I've been trying to get a minimal test function to work, which simply invokes

Hi James, > I've been trying to get a minimal test function to work, which simply > invokes _Unwind_RaiseException with a single clean-up landing pad. > However. when I run it my personality function is not getting called - > _Unwind_RaiseException simply returns apparently doing nothing. Looking > at the x86-64 assembly output from llc, I can see this is happening >

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > I've been trying to get a minimal test function to work, which simply >> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >> when I run it my personality function is not getting called - >> _Unwind_RaiseException simply returns apparently doing nothing. Looking at

On Sep 16, 2009, at 6:50 AM, Duncan Sands wrote: > Hi Bill, > >> The reason to ask this is that >>> it could make the EH tables smaller and less cluttered if we >>> elide those areas which we know don't throw (the functions called >>> are marked 'nounwind', etc.). >> Sure, that's what the SawPotentiallyThrowing boolean is for. It

On Sep 17, 2009, at 6:03 PM, Duncan Sands 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 >>>>

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

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

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

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > > Hi James, >> >> >> I've been trying to get a minimal test function to work, which simply >>> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >>> when I run it my personality function is not getting

Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some really weird stuff -- unwinds are ending up in seemingly arbitrary places... definitely not inside the caller's unwind block My target is x86. As a simple test, I tried to compile the following code and I got a segmentation fault. It looks good to me. Can someone help me out or is this a bug? define i32 @foo() {

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

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

Hi, as a language front end developer I am a bit terrified by any "unwind here will call terminate" semantics in the IR. I'd prefer the LLVM IR to be free from any assumptions about the languages compiled to it and this looks like C++ semantics sneaking into LLVM. Thus I'm under the expression the calling terminate semantics should be implemented by the front end.

Hi everyone, Since I'm busy muddying the waters by changing how exception handling works, I thought I should ask for clarification on the exact behaviour of the current 'nounwind' attribute found on functions, calls and invokes. I was thinking these would be similar to the AA analysis notes like "doesNotAccessMemory" which is a provable property of the function or call

A little while ago I asked a question on CFE-Dev about a change in the behaviour of programs using the ISO C math functions, although that question should have been put to LLVM-Dev. But I got excellent clarification of the problem anyway. However, since then I have been trying to adapt our out-of-tree implementation to get the previous behaviour. The problem is that something like: #include

Hi Mehdi, The ISO C specification does permit the math functions to modify ‘errno’, but I thought that the ‘-fno-math-errno’ option was to tell the optimiser to assume that ‘errno’ is not modified by the math functions. Explicitly providing ‘-fno-math-errno’ is not restoring the elision optimisation that was performed by LLVM v3.8, and this is really only a driver option, with ‘-fmath-errno’

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

On Dec 2, 2010, at 1:40 AM, Duncan Sands wrote: > Two amendments: > >> The semantics of the invoke instruction are slightly modified: if an exception >> unwinds and it doesn't match anything in the list of catches and filters, >> and there is no cleanup, then control doesn't branch to the unwind label, >> unwinding simply continues out of the function. >