similar to: [LLVMdev] Test approach to handling clobbering llvm.eh.selector return

Hi Garrison, > I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. > The hacked is contained within the attached patch. it looks like you tried to copy the code for eh.exception. There are two problems with this: (1) the eh.exception code really needs to be rewritten to make use of the new SSAUpdator (then all

Hi Garrison, > I accidentally ran into a JIT scenario where a call instruction, executing an external non-generated C function, > executed between a llvm.eh.exception and a llvm.eh.selector instruction would clobber the register > (register index __builtin_eh_return_data_regno(1)), used by the return value of llvm.eh.selector. The behavior > of the call depends on the function

Funny I remember that code (DwarfEHPrepare), wondering at the time why it was doing this. Thanks for your response, as I can now stop trying figure out how I am introducing this error, and more importantly now will be able to go back to DwarfEHPrepare, and understand it better knowing one of its purposes. However the result of my tests indicates that the underlying register used by the

I accidentally ran into a JIT scenario where a call instruction, executing an external non-generated C function, executed between a llvm.eh.exception and a llvm.eh.selector instruction would clobber the register (register index __builtin_eh_return_data_regno(1)), used by the return value of llvm.eh.selector. The behavior of the call depends on the function called even though none of the

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

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

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

Here http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector llvm.eh.selector is declared like this: i32 %llvm.eh.selector <http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector>(i8*, i8*, i8*, ...) But when clang++ (rev.121360) writes the module with exceptions, it writes it out like this: declare i32 @llvm.eh.selector(i8*, i8*, ...) nounwind Why there is such descrepancy?

This is an interesting problem. The GC code is being converted into 'invokes' instead of calls: define i32 @main() gc "shadow-stack" { entry: %gc_frame = alloca %gc_stackentry.main %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0, i32 1 store %gc_map* getelementptr inbounds (%gc_map.0*

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

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

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,

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

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

Hi Bill, > However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. GCC recently added support for this, i.e. a situation in which there are only cleanups to be run: it uses the C personality function even if the

I've read and re-read the LLVM exception handling doc, and there are a number of things that aren't clear to me. In the section describing llvm.eh.exception, it says "The backend replaces this intrinsic with the code that accesses the first argument of a call." I don't understand this sentence. A call to what? What is meant by 'accesses' - do you mean

On Apr 11, 2011, at 11:27 PM, Duncan Sands wrote: > Hi Bill, > >> However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. > > GCC recently added support for this, i.e. a situation in which there are

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

Hi Talin, > Since llvm-gcc is a rather large code base, which I have never looked at > (or even run), could you give me a starting point of where to look? I meant: compile some nested C++ with llvm-gcc to see what it does. Otherwise, look in llvm-convert.cpp, especially EmitLandingPads. > One thing I'd be interested in knowing is whether the > llvm.eh.exception() intrinsic can