similar to: Function with multi return path?

2017-06-02 19:51 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On 2 Jun 2017, at 03:38, TONGARI J via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > > I'm aware of the invoke instruction and landingpad. But it's too heavy > > weight for control flow. It's quite expensive to take the exceptional > path > > in C++. >

2017-06-07 22:51 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > > You could approximate this using the address-of-label extension and > passing the address of the return basic block to the function then, in the > abnormal return path, jumping to that. Doing anything else is likely to be > very complicated because the live registers at all of the potential

Hi folks, I'm new to LLVM and non-expert in hardware architecture, so my question might be dumb. I'm looking for the possibility to define/call a function with multi return path, it might look like this: ``` ; Define a function with 1 alternate return path define i32 @f(i1 %i) fork 1 { br i1 %i, label %noraml, label %alternate noraml: ... setpath ret i32 42 ; take normal return

Sorry to reply to myself here, but I had an idea regarding "issue #2" -- possibly what makes the most sense for those clients/targets is to pull the pointer difference computation/reapplication into RS4GC itself -- it could have a pass just before or after rematerialization, which runs based on a configuration flag (eventually to be driven by GCStrategy), which performs rewrites like

Thanks, I think that's a useful way to look at it (though if I wanted to bikeshed I'd suggest the name "DoubleIndirect" as a bit more precise than "VeryIndirect"). An aspect of it that I'm still puzzling over is that my target runtime (at least in its current form) doesn't have a way to represent/process a "VeryIndirect" pointer. So I'd like to

For anyone following along on ToT using the gc.statepoint mechanism, you should know that ToT is currently not able to express arbitrary exceptional control flow and relocations along exceptional edges. This is a direct result of moving the gc.statepoint representation to using a token type landingpad. Essentially, we have a design inconsistency where we expect to be able to

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

Hi Christian, > I don’t see anything in the Itanium ABI that says I need to call the function that throws an exception with “invoke” to get exception handling to work! AFAICT, it is the design of LLVM IR and its implementation. To catch the exceptions thrown by the callee functions, we should use the invoke instruction along with the landingpad instruction. If you are calling a function

On 29 Aug 2013, at 08:19, Tim Northover <t.p.northover at gmail.com> wrote: > If so, a compare that used that instruction would have to become more > like an "invoke" with a landingpad for the exception and so on, > wouldn't it? The current fcmp can already distinguish between ordered > and unordered, because ucomiss provides that information. There are currently

Hi Christian, Thanks for your explanation. I know your situation now. I would suggest you to check the optimization pass used by the JIT compiler, especially IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which will result in the problem you have mentioned earlier. Alternatively, as a workaround, try to add uwtable (function attribute) to the functions that are generated

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in 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

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with

I'm having trouble understanding the value in the way exceptions are handled on Linux, the dwarf/system V ABI exception spec. The mechanism allows for both cleanup routines and catch handlers, where by cleanup handlers don't stop the search for a normal handler. The personality function (I guess no longer part of the standard, but a C++ thing) can also compare types of the landingpads.

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

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

Hi Reid, Thanks for the input. You wrote: > The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean

On Jul 23, 2011, at 1:11 AM, Bill Wendling wrote: > On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: >> Could we add: >> >> - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. >> >> - The landingpad instruction must only appear at the top of a landing pad. It cannot appear in any other block, or

On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > // Restrictions: > > There are several new invariants which will be enforced by the verifier: > > 1. A landing pad block is a basic block which is the unwind destination of an > invoke instruction. > 2. A landing pad block must have a landingpad instruction as its first non-PHI > instruction. > 3. The landingpad

Logan, I need to make a correction of the post that preceded this one! I was wrong when I said this: > When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers? The “uwtable” attribute does not disappear! I had