search for: convokes

...sure that all EH conventions work in a similar way. > To illustrate why I don't like having the llvm.eh.exception() call > dissociated from the landing pads, what is the *exact* definition of > llvm.eh.exception: > > - Does there have to be a one-to-one correspondence between convokes > and llvm.eh.exception calls? > - Does llvm.eh.exception have to be dominated by landing pads? > - Does it just return the exception pointer from the *most recent* > landing pad that execution flowed through? > > etc. > > Maybe (this has just occurred to me) the llvm.eh.exc...

...ot;adjusted" pointer to the exception object, but you still have to pass into it a "raw" (unadjusted) pointer to the exception object. It's this raw pointer that appears magically in a native register at the start of a landing pad. > Well, be warned that there can be multiple convokes which jump to the same > landing pads. So there cannot be a one-to-one correspondence between them. > However, an llvm.eh.exception should be dominated by at least one convoke. > The only other problem I can see is if code branches into a catch block. > It's gross, but could happen....

...ng pad, but I think that is too prone to being broken by optimisation passes.) To illustrate why I don't like having the llvm.eh.exception() call dissociated from the landing pads, what is the *exact* definition of llvm.eh.exception: - Does there have to be a one-to-one correspondence between convokes and llvm.eh.exception calls? - Does llvm.eh.exception have to be dominated by landing pads? - Does it just return the exception pointer from the *most recent* landing pad that execution flowed through? etc. Maybe (this has just occurred to me) the llvm.eh.exception call could explicitly refer to...

Hi Jay, > Are you saying that, in the LLVM IR, it would be legal to have an > llvm.eh.exception that *isn't* dominated by convokes (because there's > a direct branch to that catch block), and in that case the call > returns an undefined value? this is already the case (with invoke substituted for convoke). And it would be up to codegen to "peel it > out into its own basic block"? Not sure what that me...

I've been looking into a new way to implement exception handling in LLVM. The current model has many disadvantages, in my opinion. I try to address them with this proposal. I also try to make exception handling much more understandable to the normal human reader. :-) Any new proposal will need to address all present and future languages' exception handling methodologies. I

I have a couple of questions/concerns. The main one has to do with the opacity of exception types - in other words, will it still be true that the exception types are opaque identifiers, and are only interpreted by the personality function? Since my object representations are not C++-like, I am not using any of the cxa_* C++ library functions. Instead, my code calls the _Unwind functions

>> Are you saying that, in the LLVM IR, it would be legal to have an >> llvm.eh.exception that *isn't* dominated by convokes (because there's >> a direct branch to that catch block), and in that case the call >> returns an undefined value? > > this is already the case (with invoke substituted for convoke). Good to know. It would be nice if this was clearly documented! >> And it would be up t...