similar to: [LLVMdev] problem with DwarfEHPrepare::InsertUnwindResumeCalls in multiple JIT context?

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

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

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

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 constructors which would trace entries into 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

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

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

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

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*

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

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

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

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

Duncan, It seems that the code you pasted came from the function ExpandShiftByConstant and indeed it looks correct. In my example I used 6 as the shift amount but forgot to mention that it's stored in a register. Otherwise ExpandShiftWithUnknownAmountBit wouldn't get called. Below is the execution of DAGTypeLegalizer::ExpandIntRes_Shift() using my example showing how

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

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

Hi Javier, > The problem is the implementation of the expansion. Perhaps an example > can help illustrate better. Take the case of a 64-bit integer shifted > left by say 6 bits and is decomposed using 32-bit registers. Because 6 > is less than the 32 (the register size) the resulting low part should be > equal to the source low part shifted left by 6 bits. The current >

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

Exception handling in LLVM is broken. It's as simple as that. We can simulate exception handling in most cases, but we cannot handle all cases. (For instance, SingleSource/UnitTests/ObjC/exceptions.m in our testsuite doesn't work on ARM at anything optimization level above -O0.) And there's no way to coerce it to work with our current EH scheme. We don't follow the exception