================ @@ -350,11 +350,22 @@ the destructor. Therefore, this cleanup handler is marked as eh_only. Try-catch blocks will be represented, as they are in the ClangIR incubator project, using a `cir.try` operation. +The `cir.catch_param` operation is used to represent the capturing of the +exception object in an ABI-independent way. When the catch handler includes +a source variable representing the exception object, the result of the +`cir.catch_param` operation will be stored to an alloca object for the +source variable. If the handler is a catch-all, the `cir.catch_param` operation +will return a pointer to void, but this cannot be captured by a source variable. ---------------- andykaylor wrote:
Near as I can tell, `std::current_exception` is implemented as a library call, and we don't even have a definition of it from the `exception` header. Here's the classic codegen handling: https://godbolt.org/z/1db9Tz3W7 It may be that we could attach some information to the `std::current_exception` call that would allow for some alias analysis, and possibly if we know the target ABI we could fold the result with the result of `cir.catch_param` with the call in some way, but I'm not prepared to document any such claim right now. https://github.com/llvm/llvm-project/pull/181284 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
