search for: catchpad

I think r262546 introduced the assumption that allocas are used exactly once with catchpad. It seems easy to fix, though. On Mon, Oct 17, 2016 at 11:51 PM, Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This turned out to be related to reusing the local used in the catchpad, > for example given the following c++ code: > > extern void rthrow(); > >...

I've modified llvm to emit vc++ compatible SEH structures for my personality on x86/Windows and my handler works fine, but the only thing I can't figure out is how to call these funclets, they look like: Catch: "?catch$3@?0?m3 at 4HA": LBB4_3: # %BasicBlock26 pushl %ebp pushl %eax addl $12, %ebp movl %esp, -28(%ebp) movl $LBB4_5, %eax

Hi, I'm gettign an assertion fail/crash in X86FrameLowering::GetFrameIndexReference when compiling the following bitcode: https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 I tried removing the llvm.frameaddres calls but that's not it, where can I start looking for what my mistake here is? Code seems to verify just fine. ; #0 0x00e1afe8

...r _finally, and landing in $t10 cannot be represented by LLVM IR today. Similarly in #4, the control starting from RtlRaiseException() passing through both _finally funclets then landing in $t10 was not seen. To precisely represent _local_unwind flow, our proposed solution is: * Add one more catchpad/catchret pair that forwards control to local_unwind target. I.e., this extra Catchpad is the reentrance point for the _local_unwind() runtime. * This catchpad address is used to pass to _local_unwind() runtime, instead of the original goto target address. * The local_unwind catchpad w...

This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction in @_island_debug_invoke and many other functions. The code expects either pointer to a filter function or null in first operand, while you're passing pointer to structure: catchpad within %80 [{i8*, i8*}* anon..., ...] ________________________________________ От: Carlo Kok <ck...

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >

...allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll want to look at the handling of the @llvm.eh.exceptionpointer intrinsic that's used with catchpads and basically do the same thing with landingpads. Thanks -Joseph From: Chen Li [mailto:meloli87 at gmail.com] Sent: Saturday, December 5, 2015 12:34 AM To: Joseph Tremoulet <jotrem at microsoft.com> Cc: David Majnemer <david.majnemer at gmail.com>; Igor Laevsky <igor at azulsyste...

...nsic that SEH uses). But that would require updating all the front-ends generating landingpads, and be awkward for any target personality routines that literally do pass a struct to the landing pad (are there any?), and so probably just reflects my bias coming from dealing with a personality using catchpads/cleanuppads instead of landingpads. 2) Since you're not actually using the landingpad's exception selector nor, if I understand " This is enough to support the gc.statepoint work " correctly, its exception pointer, it's possible that TLI.getExceptionPointerRegister and TLI.g...

...yout::getAlignment(llvm::Type *, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed. Thanks David! I’ve actually hacked to add token type into struct type and ended up with the same failure as above. I will take a look at the catchpad and cleanuppad code, and create a patch to add token landingpad and have you review it. thanks, chen > > As a practical matter, I fear nesting 'token' types within struct types will have similar issues. Beyond that, the design philosophy behind 'token' is that it is incred...

Op 20-3-2018 om 12:40 schreef Evgeny Leviant: > This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction > in @_island_debug_invoke and many other functions. The code expects either pointer to a filter > function or null in first operand, while you're passing pointer to structure: > > catchpad within %80 [{i8*, i8*}* anon..., ...] > > _______________________________...

...flag, the program will run successfully. The compiler problem is as follows: Prior to the Windows Exception Handling Preparation Pass, the IR for the function "test::run" contains the following: 19: ; preds = %17 %20 = catchpad within %18 [%rtti.TypeDescriptor19* @"??_R0?AVexception at std@@@8", i32 8, %"class.std::exception"** %6] %21 = load i64, i64* getelementptr inbounds ([3 x i64], [3 x i64]* @"__profc_?run at test@@QEAAXPEAVbase@@H at Z", i64 0, i64 2), align 8 %22 = add i64...

...%3 = catchswitch within none [label %BasicBlock4] unwind to caller, !dbg !93 BasicBlock3: ; preds = %BasicBlock5, %BasicBlock2 %4 = load i32, i32* %csLoc0, !dbg !94 ret i32 %4, !dbg !94 BasicBlock4: ; preds = %2 %5 = catchpad within %3 [{ i8*, i8* }* @0, i32 0, i8* null], !dbg !93 catchret from %5 to label %BasicBlock5, !dbg !95 BasicBlock5: ; preds = %BasicBlock4 br label %BasicBlock3, !dbg !95 BasicBlock6: ; No predecessors! unreachable,...

In the past people in #llvm suggested to me I should use landing pads instead of seh when it comes to Windows unless i really need seh. Looking at what gets generated win64 -gnu does use seh but calls the landing pad somehow, while win32 doesn't at all. It looks to me a custom win64 landing pad personality can also deal with things like Access Violation. Is there a way to make win32 also

...t; successfully. > > The compiler problem is as follows: Prior to the Windows Exception > Handling Preparation Pass, the IR for the function "test::run" contains the > following: > > 19: ; preds = %17 > %20 = catchpad within %18 [%rtti.TypeDescriptor19* > @"??_R0?AVexception at std@@@8", i32 8, %"class.std::exception"** %6] > %21 = load i64, i64* getelementptr inbounds ([3 x i64], [3 x i64]* > @"__profc_?run at test@@QEAAXPEAVbase@@H at Z", i64 0, i64 2), align 8 >...

Hi David, Sorry to bother you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid

...Carlo Kok <ck at remobjects.com> Отправлено: 20 марта 2018 г. 17:50 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Op 20-3-2018 om 12:40 schreef Evgeny Leviant: > This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction > in @_island_debug_invoke and many other functions. The code expects either pointer to a filter > function or null in first operand, while you're passing pointer to structure: > > catchpad within %80 [{i8*, i8*}* anon..., ...] > > _________________________________...

...3>> >> BasicBlock3: ; preds = >> %BasicBlock5, %BasicBlock2>> %4 = load i32, i32* %csLoc0, !dbg !94 >> ret i32 %4, !dbg !94 >> >> BasicBlock4: ; preds = %2 >> %5 = catchpad within %3 [{ i8*, i8* }* @0, i32 0, i8* null], !dbg >> %!93>> catchret from %5 to label %BasicBlock5, !dbg !95 >> >> BasicBlock5: ; preds = >> %BasicBlock4>> br label %BasicBlock3, !dbg !95 >> >> Basi...

...not have scopes. Without introducing new IR constructs, we could define a list of instructions that set the current region. We could write an algorithm for assigning regions to each block. The region is implicit in the IR. These are the things that could create regions: - call.preallocated.setup - catchpad - cleanuppad - lifetime.start? unclear Passes are required to ensure that each BB belongs to exactly one region. Each region belongs to its parent, and ending a region returns to the parent of the ending region. I don't think this idea is ready to be added to LangRef, but it is a good future d...

...ng new IR constructs, we could define a list of > instructions that set the current region. We could write an algorithm for > assigning regions to each block. The region is implicit in the IR. These > are the things that could create regions: > > - call.preallocated.setup > > - catchpad > > - cleanuppad > > - lifetime.start? unclear > > > > stacksave/stackrestore. > > > > I don’t think there’s any reason to make lifetime intrinsics properly > nest; nothing really cares, as far as I know. (The current lifetime > intrinsics have problems, b...

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Chris Lattner < clattner at nondot.org>: > The central idea is to use a modifiable loop tree -- similar to > LoopInfo -- as the primary representation. LLVM-IR is converted to a > loop tree, then optimized and finally LLVM-IR is generated again for > subtrees that are considered profitable. This is not a new concept, it > has already