Latest Results
Fix `SROA` when loading in multiple blocks (#7694)
## Description
Whilst trying to improve https://github.com/FuelLabs/sway/pull/7682, I
came across the following bug:
SROA was generating invalid IR when an aggregated had `load`s across
multiple blocks. When generating the scalar accesses, the older
algorithm was gathering only the "last" block that had access, and
incorrectly generating `load`s pointing to this last block, even when
the `load` was from a previous block. A "use-before-def" problem. (see
sway-ir/tests/sroa/cross_block_gep_reuse.ir).
To verify this issue this PR also creates an "SSA dominance check". We
check if all "uses" are dominated by all its "defs". But this check is
expensive, so, for the moment, this check is opt-in. Below we have some
timings to justify that:
```
dominance check off:
> hyperfine "cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release"
Benchmark 1: cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release
Time (mean ± σ): 11.213 s ± 0.100 s [User: 8.347 s, System: 1.095 s]
Range (min … max): 11.105 s … 11.383 s 10 runs
dominance check on:
> SWAY_FORCE_VERIFY_IR=true hyperfine "cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release"
Benchmark 1: cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release
Time (mean ± σ): 16.663 s ± 0.577 s [User: 13.563 s, System: 1.121 s]
Range (min … max): 16.358 s … 18.271 s 10 runs
```
This PR also removes `DCE` and `MEM2REG` passes. from the SROA test.
They were there to facilitate `filecheck` directives. As we do not use
them anymore, seeing the diff as it is, is actually better.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] 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](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] 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](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Igor Rončević <ironcev@hotmail.com> Optimize hashing by implementing `is_hash_trivial` (#7695)
## Description
This PR extends the `Hash` trait with the `is_hash_trivial() -> bool`
associated function. This function is supposed to return true if the
hash byte representation of the type is the same as its runtime memory
representation.
By using `is_hash_trivial`, `std::hash::sha256` and `keccak256` module
functions can skip expensive `Bytes` creation in the `Hasher` and
directly hash the value's memory content.
This optimization is similar to what `is_encode/decode_trivial()`
associated functions are providing for ABI encoding/decoding.
Similar to ABI encoding/decoding, implementation of hashing for a type
is in full control of the Sway package that owns the type. In practice,
and in `std` in particular, non-dynamic types are in general trivially
hashable if their packed memory representation is the same as their
runtime memory representation.
Because of this, when implementing `Hash` for tuples, we use the
`__runtime_mem_id` and the `__encoding_mem_id` intrinsics. While using
the `__encoding_mem_id` might look like coupling encoding and hashing,
it is not. What we are actually using is the notion of the "packed
memory representation" that the `__encoding_mem_id` provides.
Unfortunately, the intrinsic that provides this information was
originally created for ABI encoding and not for a more generic usage,
e.g., `__packed__mem_id`.
To make the distinction clear and remove what looks like coupling of
unrelated concepts, we will provide a follow-up PR that introduces
intrinsics for use case based memory layouts:
- `__mem_repr_id_runtime`
- `__mem_repr_id_encoding`
- `__mem_repr_id_hashing`
Currently, all enums in the `std` hash their descriminators as `u8`.
This makes them all being non-trivially hashable. For many of them,
hashing the descriminator as `u64` would make them trivially hashable.
This is however a breaking change that potentially affects the hashed
data we already have deployed, e.g., `StorageMap` keys.
In the future, we can provide this breaking change behind a feature
flag. Enums that can benefit from being trivially hashed are marked in
code with `TODO: (HASH-TRIVIAL-ENUMS)`.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] 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](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Latest Branches
-19%
ironcev/mem-repr-id-intrinsics -19%
ironcev/rollout-block-is-entry 0%
xunilrj/fix-sroa-load-multi-blocks © 2026 CodSpeed Technology