Future IR desiderata.

[otrho]

Using this issue to track bigger enhancements for IR, once we mainline it.

Improved addressing and casting.

In sway-core/src/asm_generation/from_ir.rs there are a lot of address and size calculations going on, where for all of the aggregate element accesses the offsets and sizes are attempted to be put into (usually) 12 bit immediates, so instructions like ADDI or MCPI can be used rather than the slightly more expensive (due to the extra register calculations required) ADD and MCP.

It's quite verbose and complicated and inconsistent and really should be done in IR optimisation passes. The IRgen can assume the pessimistic register based versions and an optimisation can convert it to the immediate based versions when possible. This would simplify the ASMgen greatly and probably do a better job.

This would probably require some integer casting ops to be added to IR, so that the types presented to ASMgen are strictly 12 bit integers when required.

Refactor structs while we're at it.

The design choice of using insert_value and extract_value for structs was taken in an effort to keep things simple, but in the end structs are not simple and it's not working very well. Instead we should simply lay out the structs in memory, and manage the fields with load or store. get_ptr has been upgraded now to allow casting, so it pretty much resembles LLVM GEP which is the complexity I was trying to avoid in the first place. It's inevitable though.

Management of the data section.

We load const words from the data section with a LWDataId virtual op at the moment. This is potentially wasteful for small values, especially if they're constant sizes which fit in 12 bits and therefore probably an imm for an op.

There's the potential to just use $zero or $one instead of the data section, especially for booleans.

Knowing what is const or not and can be put in the data section is currently decided by IRgen and could be refined with optimisation passes.

There's also an issue of initialising constants inside of conditional blocks which could cause undefined behaviour. See #821.

Removal of call site function inlining and proper paths for symbols.

At the moment the call nodes contain the function body of the callee and not much else about the callee is provided, including its full name or Self name (though that can be derived). This makes things harder to reason about and therefore optimise. The IR currently regenerates the callees as IR functions as not doing so (just putting the inlined code at the caller) is actually harder since each of the args to the function have to be given unique local variable names and assigned their proper values before hand (which is what doing a call is).

Eventually we don't necessarily want to inline all functions anyway.

Miscellaneous fixes.

• Resolve the aggregates code, stop pretending that structs and arrays are related.
• Re-jig the unit tests. It'd be much easier to just have the original Sway, then check it creates correct IR, and then the correct ASM from there. Different optimisations could be turned on or off explicitly.

[otrho]

All of the above is also tracked in:

• Aggregates and memory management in the IR is generally broken. #2819
• Refactor the sway-core/src/asm_generation directory. #2505
• Restructure how functions are handled in the IR and codegen to eliminate function inlining #1823
• Refactor type-checking to not inline everything #1557
• Add the collection context #1693