search for: convok

On Nov 20, 2009, at 2:15 AM, Jay Foad wrote: >> Please read and let me know your opinions! > > This definitely seems like an improvement on the current situation. > >> .---------. >> | convoke | >> `---------' >> | >> v >> .-----------------------. >> | | >> v | >> %normal .----------------+---------------. >> |...

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

> Please read and let me know your opinions! This definitely seems like an improvement on the current situation. >            .---------. >            | convoke | >            `---------' >                 | >                 v >     .-----------------------. >     |                       | >     v                       | >  %normal   .----------------+---------------. >            |                |      ...      | >      ...

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

...} or similar. This could allow optimizations based on knowing that a function cannot throw a particular type. However, it's not a particularly attractive solution. llvm.eh.personality: The next intrinsic is for the "personality function". The reason to separate this from the `convoke' instruction is because we want to prevent inlining of a function with a different personality function. void llvm.eh.personality(i8*) This also lives in the entry block for ease of finding. As with the filters, it may be beneficial to add this to the function's definition....

...n IsSubclass test. The action code returned by the personality function is a simple integer index (0, 1, 2, ...etc) which represents the number of the catch block to transfer control to. This index is then fed into a IR switch instruction in the landing pad. The concern I have is that the 'convoke' instuction takes a list of catch types, but it doesn't say what those catch types are. If the code does not assume anything about them, then I'm guessing that I would be able to adapt my code to work with it. On the other hand, if those catch types are assumed to be C++ exception...

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