SSA: Extra mem2reg pass causing failures for UHashMap

[vezenovm]

Aim

While working on #5865 our brillig_loop_size_regression program is left with a bunch of extra stores and allocates following DIE which removes any loads that reference those stores. As a quick solution to test getting to a minimal bytecode I placed an extra mem2reg and DIE pass following the previously final DIE pass. The two extra passes are not an ideal solution for #5865 due to efficiency reasons, but it is still worrisome that uhashmap would fail given an extra mem2reg and DIE pass so I am taking note of that in this issue.

Expected Behavior

I should be able to insert mem2reg anywhere in the compilation flow and not cause test failures.

Bug

Running mem2reg and DIE after the already existing DIE causes uhashmap to fail with a type mismatch:

error: Assertion failed: 'Bit size for lhs 0 does not match op bit size 32'
    ┌─ std/collections/umap.nr:358:12
    │
358 │   if self.len() + 1 >= self.capacity() / 2 {

To Reproduce

1. You can reference this commit a595349 for more context about failures.
2. The easiest way to reproduce is to add an extra mem2reg and die pass after our existing die pass.
3. For both strategies recompile and execute execution_success/uhashmap

Workaround

Yes

Workaround Description

Do not run mem2reg after DIE

Additional Context

No response

Project Impact

Blocker

Blocker Context

Not a current blocker, but definitely has the potential to block in the future

Nargo Version

No response

NoirJS Version

No response

Proving Backend Tooling & Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[vezenovm]

Closing this as the cause this failure was due to inappropriately accounting for reference params #5865 (comment) and AztecProtocol/aztec-packages#8448 removed the need for a re-load and store when laying down inc/dec rc instruction