Similarly to YJIT, could we skip the call when the val is known to be an immediate? I guess we could let the HIR generator check the type and set a flag to Insn::SetLocal like write_barrier: true.

Feel free to merge this first and leave it for another PR though.

tbh we don't need a flag in the instruction -- we can make the decision at HIR->LIR codegen time with the type of val

@st0012 does this (with the class.h fix) fix the problems you see and enable more tests?

"with the type of val", yes. What I'm saying is that I thought the HIR generator has better/more access to the type of val, but I might be wrong. If we want to optimize only the case that it points to Opnd::Value (likely created by Insn::Const) and the VALUE of it is an immediate, the HIR can stay as is. I was worried about cases like val pointing to Insn::GuardType, but maybe find() resolves it into Insn::Const when possible?

I figure things like GuardType on a constant should be handled by optimizer, so HIR->LIR translation should have the same visibility on whether something is constant.

I mean that in HIR->LIR you can do if val.is_subtype(types::Immediate) and not care at all about what instruction it comes from. That will use all available information from the optimizer

That gives (much) more information than looking at the exact value, which we might not know. It would handle if it's any kind of Fixnum, for example

I mean that in HIR->LIR you can do if val.is_subtype(types::Immediate)

I'm not sure if I follow. is_subtype() is a function on Type, but val is hir::InsnId in HIR and lir::Opnd in codegen. How do you call is_subtype() on val?

Ah, I guess Function::insn_types keeps them for each InsnId. Nvm then. I guess we don't need to bake type-related information in the instruction itself because the function has it separately.