Do we still need Ty::Unimplemented?

[ltratt]

It feels like an odd enum variant for us to have to deal with: shouldn't it cause trace_builder to bork before it gets passed to the backend? But perhaps there's something here I haven't thought about!

[vext01]

Looking at our IR serialiser, unimplemented types are emitted into the AOT IR when one of the following types are encountered:

• Less-common floating point types (half, bfloat, bfloat, f128, x86_fp80, ppc_fp128).
• Opaque structs.
• Vector types.
• Array types (these are separate from arrays allocated with alloca, whose type are simply ptr).
• Other unusual types, e.g. X86Amx, target extension types, token, etc.

The only reason we can't handle these types is that we haven't implemented a lowering. That said, some of these I expect are unlikely to ever be encountered in non-pathological programs, simply because they are just so rare/obscure (e.g. bfloat).

Why don't we just crash the serialiser when we encounter a type we can't handle? By deferring the crash to runtime it means we can JIT more programs if the AOT module contains a type we can't handle somewhere. As long as that type doesn't arise in traced code, we can still JIT that path.

Why don't we emit an unimplemented instruction instead, if an operand of an instruction is a type we can't handle? It makes the serialiser more complex, as we would have to insert code to check types of operands in lots of places.

Now to answer your question:

shouldn't it cause trace_builder to bork before it gets passed to the backend?

We could certainly do that. It would make the JIT IR more concise. In such a scenario we could abort tracing with an appropriate YK_LOG message and carry on. The AOT IR would still need the notion of an "unimplemented type".

Hope this helps.

[ltratt]

shouldn't it cause trace_builder to bork before it gets passed to the backend?

We could certainly do that.

I think that would be best, as it would mean that nothing downstream of trace_builder needs to worry about this. [I do buy the "if we bork on Unimplemented in ykllvm, we might struggle to compile anything" argument".]

So I'm going to change this issue title, and it can be (hopefully!) an easy enough task to address this in trace_builder.