Optimise get_config for trivial types

[xunilrj]

Description

This PR optimize access to trivially decodable configurables.

We know that decode for these configurables is essentially a noop. So now we do not run their decode and simply point to the configurable section directly.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[codspeed]

Merging this PR will not alter performance

✅ 25 untouched benchmarks

---

_{Comparing xunilrj/opt-get-config (ebca105) with master (f26c42c)}

[xunilrj]

I think I found the reason for the regressions. This is an example from o2.

get_config before this optimization generates just one ADDI, as apps normally do not have enough configurables to overflow ADDI immediate argument. With the new optimization, on the other hand, apps normally DO have enough bytes in their data section to overflow it, so we end-up with two instructions: MOVI and ADD.

BEFORE

addi $r0 $ssp i1              ; get address of configurable BASE_ASSET

0x00001808 ADDI R52 $ssp 0x1                               ;; [80, 208, 64, 1]

AFTER

addr $r0 data_Configurable_1  ; get address of configurable BASE_ASSET

0x00001630 MOVI R52 0xd30                                  ;; [114, 208, 13, 48]
0x00001634 ADD R52 R52 R63                                 ;; [16, 211, 79, 192]

The regression then occurs when the number of access compensates the gain of removing the decode.

[ironcev]

@xunilrj Regarding the large data section, it is likely we can improve there in general. E.g., I've noticed cases where we have a large number of u64s in the data section: #7612

[xunilrj]

order-book binary size:
Before: 124.56 KB
After: 124.12 KB (0.3% better)

fuel-o2-exports

	Improvements	Regressions
Count	32	1
Average	0.61%	-0.04%
Median	0.64%	-0.04%
Max	1.35%	-0.04%
Min	0.04%	-0.04%

[xunilrj]

order book

	Improvements	Regressions
Count	25	10
Average	0.90%	-0.06%
Median	0.96%	-0.06%
Max	1.52%	-0.09%
Min	0.15%	-0.03%

"single_level/total_gas",1588956,1590246,-0.08
"single_level/gas_per_match",3177,3180,-0.09
"multi_level/total_gas",2094872,2096400,-0.07
"multi_level/gas_per_match",4028,4031,-0.07
"max_throughput_worst_case/total_gas",20973262,20979761,-0.03
"max_throughput_worst_case/gas_per_match",17536,17541,-0.03

trade account

	Improvements	Regressions
Count	21	—
Average	0.18%	—
Median	0.17%	—
Max	0.27%	—
Min	0.08%	—

[xunilrj]

I had to remove the idea of having "$cs" for now. It was causing some annoying regressions exactly in hpt paths. The issue is that we were decreasing the allocation pool, and one of the affected methods was exactly in a important method inside the order-book contract.

Nor order-book, nor trade-account contracts have trivial configurables after the limit of 12 bit offsets. We can try to improve this case later in multiple ways without reserving a new register.

fuel-o2-exports / order-book

	Improvements	Regressions
Count	35	—
Average	0.50%	—
Median	0.52%	—
Max	0.77%	—
Min	0.21%	—

Distribution

Histogram for Percentage (bars: 10, sum: 35n, max: 8n):

>= 0.21   <  0.266  |2n   5.71%|■■■■■■■■■■                             |
>= 0.266  <  0.322  |8n  22.86%|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■|
>= 0.322  <  0.378  |2n   5.71%|■■■■■■■■■■                             |
>= 0.378  <  0.434  |3n   8.57%|■■■■■■■■■■■■■■■                        |
>= 0.434  <  0.49   |1n   2.86%|■■■■■                                  |
>= 0.49   <  0.546  |2n   5.71%|■■■■■■■■■■                             |
>= 0.546  <  0.6020 |2n   5.71%|■■■■■■■■■■                             |
>= 0.6020 <  0.6580 |5n  14.29%|■■■■■■■■■■■■■■■■■■■■■■■■■              |
>= 0.6580 <  0.7140 |3n   8.57%|■■■■■■■■■■■■■■■                        |
>= 0.7140 <= 0.77   |7n  20.00%|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■    |

fuel-o2-exports / trade-account

	Improvements	Regressions
Count	21	—
Average	0.24%	—
Median	0.24%	—
Max	0.36%	—
Min	0.10%	—

Distribution

Histogram for Percentage (bars: 10, sum: 21n, max: 4n):

>= 0.1    <  0.126  |2n   9.52%|■■■■■■■■■■■■■■■■■■■■                   |
>= 0.126  <  0.152  |1n   4.76%|■■■■■■■■■■                             |
>= 0.152  <  0.178  |4n  19.05%|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■|
>= 0.178  <  0.204  |2n   9.52%|■■■■■■■■■■■■■■■■■■■■                   |
>= 0.204  <  0.2299 |0n   0.00%|                                       |
>= 0.2299 <  0.256  |3n  14.29%|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■         |
>= 0.256  <  0.2820 |2n   9.52%|■■■■■■■■■■■■■■■■■■■■                   |
>= 0.2820 <  0.3080 |0n   0.00%|                                       |
>= 0.3080 <  0.3340 |4n  19.05%|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■|
>= 0.3340 <= 0.36   |3n  14.29%|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■         |

[ironcev]

👍