search for: cleanuppad

...nment(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 incredibly opaque and...

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

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

...%cleanup1 cont2: call void @use_callsetup(i8* preallocated %m1, i32 13, i8* preallocated %m2, i32 42, i8* preallocated %m3) [ "callsetup"(token %cs) ] cleanup1: %cl1 = cleanuppad unwind to caller call void @dtor(i8* %m1) [ "funclet"(token %cl1) ] cleanupret %cl1 to label %cleanup0 cleanup0: %cl0 = cleanuppad unwind to caller call void @dtor(i8% %m0) [ "funclet"(token %cl2) ] cleanupret %cl0 to label %cleanupCall cleanupCall: %clC = cleanupp...

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

...opes. 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 direction, per...

On Wed, Apr 4, 2018, at 08:58, Carlo Kok via llvm-dev wrote: > That's quite likely. I can reproduce this issue with llvm 6.0 though. > I'll try with svn HEAD. > > On Tue, Apr 3, 2018, at 19:22, Reid Kleckner wrote: > > I would guess that %threedoubles has a large alignment and that is making things go wrong. I thought we fixed this bug, though. I can't find it in

...(i8 0, i8* %31) #7 to label %32 unwind label %39, ; <label>:32: ; preds = %30 %33 = call i8* @llvm.localaddress(), invoke void @"?fin at 0@main@@"(i8 0, i8* %33) #7 to label %34 unwind label %43, ; <label>:34: ; preds = %32 br label %53, ; <label>:35: ; preds = %27 %36 = cleanuppad within none [], %37 = call i8* @llvm.localaddress(), invoke void @"?fin at 0@main@@"(i8 1, i8* %37) #7 [ "funclet"(token %36) ] to label %38 unwind label %39, ; <label>:38: ; preds = %35 cleanupret from %36 unwind label %39, ; <label>:39: ; preds = %38, %35, %30 %40...

...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, but I don’t think that’s...

That's quite likely. I can reproduce this issue with llvm 6.0 though. I'll try with svn HEAD. On Tue, Apr 3, 2018, at 19:22, Reid Kleckner wrote: > I would guess that %threedoubles has a large alignment and that is making things go wrong. I thought we fixed this bug, though. I can't find it in the tracker, but it's in there. Someone used __try with local variables of type

Sorry for the delay. Arthur Eubanks has started working on the design here: https://reviews.llvm.org/D74651 I felt I should follow up here about that. On Mon, Jan 27, 2020 at 6:47 PM Eli Friedman <efriedma at quicinc.com> wrote: > It doesn’t seem like multiple call sites should be a problem if they’re > sufficiently similar? If the argument layout for each callsite is the > same,