Toby Hutton

#2394 has now made it so there can be only one MD tag per item, so the commas are probably redundant. So I won't close this quite yet.

Aren't we going to have different intrinsics for different targets? So maybe since these are Fuel specific they should be `__fuelvm_state_load_word()` and we can have `__evm_state_load_word()` eventually too. And, then...

I was thinking yeah, a certain subset of intrinsics will just not compile, with an error, if your target isn't right for them. Some intrinsics simply won't exist for certain...

There is one intrinsic whose behaviour is entirely data driven based on the target. You could add or modify targets without having to change the actual compiler core/type checker.

Fair enough, although it's probably just worth a warning rather than full on error.

> Looking closer at the diff. Has this actually been rebased onto master properly? Considering the age of the original PR (you said it was 20 days old?) I imagine...

OK, so the allocator just treats the dynamic jumps as static jumps based on the metadata and preserves the destination register and we're fine?

> I suppose this is deprioritized after your calls PR goes in anyway, since bytecode size will be much smaller. Hopefully, but this is still a problem and needs addressing....

I put something into the `opt` binary (`sway-ir/src/bin/opt.rs`) which resembles something we might at least start with.

The hardest part of removing inlining (and supporting recursion) is supporting actual function calls. I can't find an issue for this though at the moment. Function calls are typically done...