Memory Layout

[xunilrj]

Whilst finishing up #4929 I realized that the memory layout code is scattered through out the code. This poses the obvious problem of having to keep everything in sync, but also will not allow the layout to be controlled using #repr() in the future.

This issue will work as a bookmark to places that needs to be refactored to improve and allow customization:

1 - Data Section: at sway-core/src/asm_generation/fuel/data_section.rs. Special attention will be needed at the from_constant because we don't have a way to describe a enum without hacks. See comments at line 98;

2 - Locals: at sway-core/src/asm_generation/fuel/functions.rs inside alloc_locals and init_locals we also need to take into consideration the memory layout of objects.

3 - Realizing loads: at sway-core/src/asm_lang/allocated_ops.rs inside realize_load.

4 - Size* Intrinsics: Intrinsics that return the size of types and instances also need to take memory layout into consideration.

5 - Calling conventions: We need to also consider all of our calling conventions:
5.1 - Entry call and return: We have a special case when the argument/return value fits into the VM register or not. Depending on the case the layout of basic data types change;
5.2 - Contract calls at sway-core/src/ir_generation/function.rs in compile_contract_call : Similiar to above;

6 - Storage: at sway-core/src/ir_generation/storage.rs

7 - Sroa at sway-ir/src/optimize/sroa.rs needs to know the offset of each field and end up calling get_indexed_type at sway-ir/src/irtype.rs . Of course that in this same file size_in_bytes also needs to take layout into account.

A difficult question is if this will need to affect anything inside our IR. Maybe GEP will need to have access to type information.

[ironcev]

Excellent compilation! A clear call to a good refactoring.