search for: dwarfehprepare

Hi, I was wondering if there are any known issues with DwarfEHPrepare::InsertUnwindResumeCalls when using JIT? It appears that the block of code below in this function doesn't correctly handle the case where the rewind function is removed from the module by some other pass (when its unused for instance), and multiple functions are JITed. The RewindFunction vari...

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

...nctions with static variables initialized in a certain way do the trick. I am assuming > that this is not a bug but rather that there is an unstated requirement that llvm.eh.exception, and llvm.eh.selector > must be the first calls in any landing pad. Is this true? no, it's a bug. The DwarfEHPrepare is supposed to take care of moving such calls to the start of landing pads, but currently it only does this for eh.exception (eh.selector is harder for various reasons). This is on my list of things to fix. Ciao, Duncan.

Hi Duncan, 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. Motivation: I recently created a decent amount of hand coded IR (via the llvm C++ API). In order to help me runtime debug the code, I created automatic construc...

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

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

...ctor() ; code to clean up. The call to @bar can insert an arbitrarily complex amount of code, including invokes, llvm.eh.selector calls, etc. Because there is no relationship between the invoke of @foo and %eh_sel in ppad, we lose that information at ppad, which is where we need it. The code in DwarfEHPrepare::MoveExceptionValueCalls that moves the call to llvm.eh.exception into the landing pad, and which you want to do for llvm.eh.selector as well, will only complicate matters. It would introduce PHI nodes for llvm.eh.selector values like it currently does for llvm.eh.exception values. > invoke v...

.... 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. Also note that the landing pad of the 'invoke' doesn't include any of the exception handling intrinsics. During the DwarfEHPrepare pass, an @llvm.eh.exception() call is added (thus marking that as a "landing pad" in code-gen), but there isn't an equivalent @llvm.eh.selector call. I don't know enough about GC stuff to say what should happen here. Though it looks like we at least need the gc_cleanup to generat...

...to say what should happen here. Though it looks like we at least need the gc_cleanup to generate an llvm.eh.selector call at the very least...The question becomes which personality function it should call, because that's language-specific. One reason I added lowering for "unwind" in DwarfEHPrepare was to help handle this situation: an invoke followed by some cleanup code followed by unwind. I had GC lowering in mind. I think the only thing missing is having the code generators use the C personality function by default if there is no personality function, but as I didn't work on this fo...

...nd possibly linking in > parts of its own runtime that depend on this information being correct? > I would say that the coupling between LLVM generated code and the HP unwind interface is pretty low. The only call LLVM emits is to _Unwind_Resume, so you would have to go into llvm/lib/CodeGen/DwarfEHPrepare.cpp and teach LLVM what you want it to call in your runtime for your EH personality. Other than that, LLVM mostly emits ehframe unwind info and the LSDA, which describes the landingpad PCs and how to get there. You can either try to interoperate with that, or you'll have to change LLVM to emit...

...nounwind declare i8* @llvm.eh.exception() nounwind readonly declare i32 @llvm.eh.selector() nounwind declare i32 @__gxx_personality_v0(i32, i64, i8*, i8*) declare void @_ZSt9terminatev() noreturn nounwind How is it codegened ------------------- Code generation is like now, only simpler. The DwarfEHPrepare pass, which currently has to do crazy things about catch-all's will still exist but much simpler: it just has to ensure that the value of eh.selector makes sense no matter where it is declared, like it does already for eh.exception, in fact the same code could be used for both. Currently when...

...g is the "or" of the foo and bar >> cleanup flags. The catches are the bar catches followed by the foo >> catches. > > You are greatly underestimating the amount of work the inliner has to do under this proposal. In fact, the only thing that your proposal simplifies is DwarfEHPrepare. needless to say, I disagree :) See below. > The inliner would still need to do two extra things: > > 1. It would need to adjust landing pads so that they forward selectors they don't understand to the enclosing landing pad. Consider the following code: > > void a(); >...

...e. Tagging the edges solves the problem for clients with a handle on an edge; clients that want to go from (say) a dispatch to its landing pad(s) will still have trouble. > We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of hacks to get around our poor EH support. While I agree that the hacks need to go, there is always going to be some amount of custom codegen for EH just to get the special data to flow properly from landing pads to th...

...The cleanup flag is the "or" of the foo and bar > cleanup flags. The catches are the bar catches followed by the foo > catches. You are greatly underestimating the amount of work the inliner has to do under this proposal. In fact, the only thing that your proposal simplifies is DwarfEHPrepare. The inliner would still need to do two extra things: 1. It would need to adjust landing pads so that they forward selectors they don't understand to the enclosing landing pad. Consider the following code: void a(); void b() { try { a(); } catch (int i) {} } void c() { try { b()...

...o resume edge If we have inlining of any of those d'tor calls, we may lose the fact that the dispatch in, say, lp1 is a cleanup that lands onto the region 2 dispatch in lp2. We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of hacks to get around our poor EH support. On a personal level, I'm not a big fan of forcing constraints on code when they aren't needed. We had problems in the past (with inlining into a cleanup part of an EH...

...t that troublesome. The dispatch would give you the region number. All objects in the function with that region number will point to the landing pad(s) for that region. >> We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of hacks to get around our poor EH support. > > While I agree that the hacks need to go, there is always going to be some amount of custom codegen for EH just to get the special data to flow properly from landing...

...ow the ABI, our exception handling is slow (and people have noticed). We call _Uwind_Resume_or_Rethrow, which is expensive and unnecessary. Inlining is a huge problem for our current EH scheme. Its inability to properly inline cleanups is the reason why I had to create the (very expensive) hack in DwarfEHPrepare. And in the case of SingleSource/UnitTests/ObjC/exceptions.m, it simply fails. The inlining code has to create "catch-alls" that throw and catch within the same function. To see an example of this, compile this simple code into LLVM IR: #include <iostream> struct A { ~A(); }; v...

...can have multiple landing pads. This is actually a pretty central question in the design. Plus the answer to #2 may obviate the need for discussion on #1 anyway. >>> We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of hacks to get around our poor EH support. >> >> While I agree that the hacks need to go, there is always going to be some amount of custom codegen for EH just to get the special data to flow properly from...

..." of the foo and bar >>> cleanup flags. The catches are the bar catches followed by the foo >>> catches. >> >> You are greatly underestimating the amount of work the inliner has to do under this proposal. In fact, the only thing that your proposal simplifies is DwarfEHPrepare. > > needless to say, I disagree :) See below. Well, I was talking about the proposal you actually made, as opposed to your second proposal made ten hours after my response. :) I agree that your second proposal solves the obvious inlining problems with your first proposal. John.

...at should happen here. Though it looks like we at least need the gc_cleanup to generate an llvm.eh.selector call at the very least...The question becomes which personality function it should call, because that's language-specific. > > One reason I added lowering for "unwind" in DwarfEHPrepare was to help handle > this situation: an invoke followed by some cleanup code followed by unwind. I > had GC lowering in mind. I think the only thing missing is having the code > generators use the C personality function by default if there is no personality > function, but as I didn...