[PATCH] D12533: [WinEH] Add llvm.eh.padparam intrinsic

Joseph Tremoulet via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 1 09:45:33 PDT 2015


JosephTremoulet added a comment.

Yes, it was ironic that `eh.padparam` ended up with the fully-general signature.  That was simply an attempt to match the "look-and-feel" of the other EH operators/intrinsics, which are typically abstracted over the personality function.

> What use cases do you have for the additional parameters to padparam?


I wasn't planning on using any in LLILC (the only extraction I need is to get an exception pointer from a `catchpad`), I just included them in the opcode signature to give flexibility for other personalities.

> If the extra parameters are used like an enum, where the backend has to switch on it and use custom code for different cases, then I think individual intrinsics are the way to go. If the extra parameters are more like an index into a list of register parameters (RCX, RDX, R8, R9, ...) or an index into argument stack slots, then llvm.eh.padparam seems like a reasonable approach.


I agree with that view.  I was imagining an outer switch on personality function, and that the selector arguments if used would likely index into a parameter list.

I'm certainly not wedded to keeping padparam this general.  The specific signature that I need is `exception_aggr addrspace(1)* @llvm.eh.intrinsicname()` (or I could get by with `i8 addrspace(1)* @llvm.eh.intrinsicname()` and bitcasts).  I guess for my specific case `intrinsicname` would be `get_clr_exception` or something.  If you'd prefer that, let me know what you think the name should be and whether you want any of the ones you listed included in this patch, and I'll be happy to change it.


http://reviews.llvm.org/D12533





More information about the llvm-commits mailing list