search for: landingpadinst

Chris, it is goodness that the LandingpadInst will be pinned to the beginning of a BasicBlock,... except for the possibility of PHINode instructions that _must_ come even earlier.?. I can't exactly put my finger on what's going to go wrong with this, but it sure smells fishy... my current understanding is that the LandingpadIns...

...t have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path. -Andy On Aug 4, 2011, at 4:04 PM, Peter Lawrence wrote: > Chris, > it is goodness that the LandingpadInst will be pinned to the beginning > of a BasicBlock,... except for the possibility of PHINode instructions that _must_ > come even earlier.?. > > I can't exactly put my finger on what's going to go wrong with this, > but it sure smells fishy... > > > my current un...

Andrew, yes, my brain-bad, soon after I hit the Send button I realized it is the InvokeInst that starts the lifetime of those hard-registers, not the LandingpadInst, but you beat me to the reply. -Peter Lawrence. On Aug 4, 2011, at 4:16 PM, Andrew Trick wrote: > Hi Peter, > > Thanks for pointing this out. Some us who are concerned with > codegen have discussed the problem. Although the details aren't > decided, you can be sure that a...

Guys, on second thought... doesn't making the exception registers live from the InvokeInst to the LandingpadInst create problems for critical-edge-splitting ? if a landingpad-edge is critical and needs to be split, won't we be creating and inserting a new BB between the "invoke-block" and the "landingpad-block", and if we do then isn't there the possibility of the register all...

Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports multiple filter-lists on a single LandingpadInst. first off...

On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote: > Bill, > ooops, yes, I described the meaning of "throw(A)" backwards, I thought that might be the case. :) > but I still > think my example shows why you cannot merge LandingpadInst while > inlining because multiple filter-lists on a LandingpadInst don't make sense. > > Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading > Duncan's emails, but I read them to mean that your syntax supports > multiple filter-lists on a single Lan...

...39;resume' instruction), you can use the 'insertvalue' instruction. The code it produces is more verbose, but after optimizations, code-gen typically doesn't produce a lot of code for these sequences. I copied that bit of code from ExceptionDemo.cpp (lines 1270-1290): > llvm::LandingPadInst *caughtResult = > builder.CreateLandingPad(ourCaughtResultType, > personality, > numExceptionsToCatch, > "landingPad"); > // ... > > builder.CreateStore(caughtResult, caugh...

On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote: > However it seems that if a landingpad-block has multiple predecessors (often the case, > multiple InvokeInst in the main body of a try-statement all go to the same landingpad- > block), then you cannot move the LandingpadInst in order to break a critical edge unless > you do it for _all_ landingpad-block predecessor edges simultaneously, but that seems > to be a messy conclusion (being forced to split other edges that don't need to be split). > > > my first guess is that all the nuances of whether...

...ested in an updated summary as well, especially any thoughts > you have on when the various pieces might come online and where extra hands > could be helpful; we're eager to build our EH support in LLILC on top of > this. > A preliminary step was to push personality routines off of LandingPadInst and onto functions, this is already in trunk. On the IR front, we ended up with the following set of instructions: catcblock, catchret, cleanupblock, cleanupret, terminateblock Of these, I've locally added basic support for catchblock, catchret and cleanupret. I'm working on cleanupbloc...

On Aug 4, 2011, at 4:03 PM, Peter Lawrence wrote: > Bill, > I believe the empty-exception-specification example is a red-herring, > but that if you can construct an example where you think a landing-pad > requires multiple filter lists then I think we can then have a productive > conversation about it. > > I believe we can only get multiple filter lists in a

...David Blaikie wrote: >> Knowing nothing about any of this stuff, I do find this a bit surprising - usually values are opaque to their consumers: they're just a value. So i actually know nothing about this either. When i originally found the crash, personality functions were still on the LandingPadInst itself. I agree that typically its fine to be able to use opaque values. Unless we actually have to introspect the personality Function*, eg, for calling conventions, then I think its fine to allow any value. In fact, it looks like classifyEHPersonality was written to support this. Pete >&gt...

Bill, I believe the empty-exception-specification example is a red- herring, but that if you can construct an example where you think a landing-pad requires multiple filter lists then I think we can then have a productive conversation about it. I believe we can only get multiple filter lists in a landing-pad if we attempt to merge exception-regions, and since filters are only an

...on-IR way of interpreting the struct. So we're kind of back to the situation we have with the intrinsics... I agree with Bill in this case. The reason for landingpad to be an instruction is a) make it clear that it is magic in several ways (e.g. pinned to the start of a block), and b) so that LandingPadInst can have a bunch of useful accessors on it. -Chris

On Jul 31, 2011, at 11:06 AM, Duncan Sands wrote: >> //===-------------------------- >> // The 'landingpad' Instruction >> // >> >> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >> 'llvm.eh.selector' intrinsics. >> >> // Syntax: >> >> %res = landingpad<somety>

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

On Apr 8, 2012, at 8:47 AM, Paul J. Lucas wrote: > On Apr 8, 2012, at 4:20 AM, Bill Wendling wrote: > >> On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote: >> >>> This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are

...onst dtor_blk = BasicBlock::Create( ctx, "dtor", fn ); > builder.SetInsertPoint( dtor_blk ); > builder.CreateCall( dtor, void_obj_ptr ); > builder.CreateBr( unwind_blks_.back() ); > > // Catch exception, if any. > builder.SetInsertPoint( unwind_blk ); > LandingPadInst *const lpad = builder.CreateLandingPad( > caught_result_type_, personality_fn_, 0 > ); > lpad->setCleanup( true ); > builder.CreateStore( lpad, caught_result_storage_ ); > builder.CreateStore( exception_thrown_state_, exception_caught_flag_ ); > builder.CreateBr(...

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

...// insert into vector -HANDLE_OTHER_INST(55, ShuffleVector, ShuffleVectorInst) // shuffle two vectors. -HANDLE_OTHER_INST(56, ExtractValue, ExtractValueInst)// extract from aggregate -HANDLE_OTHER_INST(57, InsertValue, InsertValueInst) // insert into aggregate -HANDLE_OTHER_INST(58, LandingPad, LandingPadInst) // Landing pad instruction. - LAST_OTHER_INST(58) + FIRST_OTHER_INST(46) +HANDLE_OTHER_INST(46, ICmp , ICmpInst ) // Integer comparison instruction +HANDLE_OTHER_INST(47, FCmp , FCmpInst ) // Floating point comparison instr. +HANDLE_OTHER_INST(48, PHI , PHINode ) // PHI node ins...

On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at philipreames.com> wrote: > Since I haven't been following the thread closely, is there an updated > summary of the original proposal available? I know that various parts I > had concerns with (the unsplitable blocks for instance) got addressed, but > I'm having trouble tracking all the changes in discussion.