Closed steven-johnson closed 5 months ago
This function shouldn't call halide_error. Halide_error is called at the Halide IR level if it fails, with a more informative error message (it names the Func)
Would be nice to in some way distinguish in the type system which parts of the runtime should return an error code and have already called halide_error, vs which parts return an error code that still needs a call to halide_error to happen above.
Would be nice to in some way distinguish in the type system which parts of the runtime should return an error code and have already called halide_error, vs which parts return an error code that still needs a call to halide_error to happen above.
Yeah, everything about error handling in the runtime is messy. A few years ago I started work on a proposal to rationalize it but ended up abandoning it.
This function shouldn't call halide_error. Halide_error is called at the Halide IR level if it fails, with a more informative error message (it names the Func)
Surely you don't mean that we shouldn't call it anywhere in halide_debug_to_file()?
PTAL
I do mean that. It produces an error message with less information than if we just return an error code without calling halide_error, and if halide_error has been overridden to return instead of aborting. It produces two error messages for the same error.
PTAL -- I can use StackStringPrinter if you prefer but the underlying codegen will likely be identical, LMK
Gentle Review Ping
Built on top of https://github.com/halide/Halide/pull/8175, this adds .npy as an option. This is actually pretty great because it's easy to do something like
in Python and get nicely-formatted output, which can sometimes be a lot easier for debugging that inserting lots of print() statements (see https://github.com/halide/Halide/issues/8176)
Did a drive-by change to the correctness test to use this format instead of .mat.