Some builtin intrinsics (e.g., sin) are generic and artic allows to pass any type to them. This however crashes down the pipeline in thorin, which is not able to handle arbitrary types for that specific intrinsics.
The following is a simple example of such misuse which might occur very easily due to regression/refactoring:
struct ABC {
a: f32,
b: f32,
c: f32
}
// Same as in intrinsics_math.impala in AnyDSL runtime
#[import(cc = "builtin")] fn sin[T](T) -> T;
// Some imaginary functions to prevent optimization
#[import(cc = "C", name = "foo_f32")] fn foo_f32(_: f32) -> ();
#[import(cc = "C", name = "foo_abc")] fn foo_abc(_: ABC) -> ();
#[export] fn main() -> () {
// The following works
let v = 42:f32;
foo_f32(sin(v));
// This does not work and has to be caught somehow, as artic thinks it is valid
let abc = ABC { a=4, b=2, c=0 };
foo_abc(sin(abc));
}
Catching and printing (always!) an error would be a good initial way to approach this. Currently, artic crashes and thorin prints an error when checks are enabled (which is off by default).
A better way is to prevent such misuse by utilizing implicits.
Some builtin intrinsics (e.g.,
sin
) are generic and artic allows to pass any type to them. This however crashes down the pipeline in thorin, which is not able to handle arbitrary types for that specific intrinsics. The following is a simple example of such misuse which might occur very easily due to regression/refactoring:Catching and printing (always!) an error would be a good initial way to approach this. Currently, artic crashes and thorin prints an error when checks are enabled (which is off by default).
A better way is to prevent such misuse by utilizing implicits.
thorin: https://github.com/AnyDSL/thorin/commit/cf797d7bb8744e7408c6a42f4e60be835cfe5ca2 artic: 2263837c4968b1bd40041463efcce9e96f281bb1
PS: This has no high-priority, but is an issue by design due to bad error management and must be handled in the future.