Support the graphblas.throw op

[paul-tqh-nguyen]

It'd be nice to do some runtime checks in our MLIR code.

• For example, if we have a function taking in a tensor<?x?xf64, #CSR64> where the function assumes the input is square, it'd be nice to actually check that at runtime.
• Another example is when we pass in an int32 tensor when the function expects a tensor<?x?xf64, #CSR64>. We'd just get a segfault and lose a lot of time debugging.

We could solve these problems with safety checks that use exceptions. Since I was unable to find any MLIR-specific exception throwing functionality, I think the solution is to implement our own graphblas.throw.

• graphblas.throw would lower down to a call to an external C/C++ function that just throws some exception. The LLVM dialect supports global strings that we could use for error messages. Alternatively, we could make the error message a compile-time constant/op attribute.
• Since sparse tensor support currently boils down to a bunch of function calls to external C/C++ functions, we're not doing anything less clean than what we're already doing.

[seibert]

In principle, this seems reasonable, but I'm worried / concerned that we won't be able actually catch these exceptions. The mechanics of C++ exceptions are pretty complicated. Can we do a quick test to check the feasibility of this?

[seibert]

OK, had a quick chat with Siu and it seems there are a number of reasons this won't work the way we want it to. C++ exception are a bit fragile and magical, and not going to work across shared library boundaries.

The way a number of other languages (Rust, Go) handle this is forbid exceptions entirely and make operations that can fail return a tuple with a bool for success and the actual return value. Then you can check the success flag and return if it fails. CPython does a similar thing, but setting a global exception pointer with the Exception object.

[seibert]

Also, even aside from the stack unwinding issues, the other challenge with exceptions is memory management and leakage

[paul-tqh-nguyen]

I made partial progress on this ticket in https://github.com/paul-tqh-nguyen/mlir-graphblas/commit/167d4cc96f4ad04d3384680b587a9aee14067c44 prior to reading the concerns mentioned in https://github.com/metagraph-dev/mlir-graphblas/issues/104#issuecomment-894459272. I don't think this is a waste of effort since these changes can be easily turned into a graphblas.comment op that we talked about but never implemented.