feat(mlir): enable the spill-retry protocol for the MLIR pipeline

[abinavpp]

NomicFoundation/solx-llvm#142

[Copilot]

Pull request overview

This PR updates the MLIR-based compilation pipeline to support the spill-retry protocol by keeping memoryguard symbolic through MLIR lowering and then folding it into a constant in the LLVM module before LLVM optimization runs.

Changes:

• Updates the MLIR convert-yul-to-std pass binding and usage to keep memoryguard symbolic via a new symbolic_mem_guard parameter.
• Adds a pre-optimization fold step in the EVM codegen context to rewrite llvm.evm.memoryguard calls into constants based on spill_area_size.
• Updates Sol dialect array type construction stub to the newer API shape (optional fixed-size vs dynamic).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
solx-mlir/src/ffi.rs	Updates the MLIR pass FFI binding to accept symbolic_mem_guard.
solx-mlir/src/context/mod.rs	Uses the new pass constructor and documents symbolic memoryguard behavior in the pass pipeline.
solx-mlir/sol_attr_stubs.cpp	Updates Sol dialect ArrayType construction to use an optional size representation.
solx-core/src/project/contract/mod.rs	Folds symbolic memoryguard in the MLIR→LLVM path before running optimization/codegen.
solx-codegen-evm/src/codegen/context/mod.rs	Introduces fold_memory_guard to rewrite llvm.evm.memoryguard into constants and capture the guard value.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Coverage Summary

Crate	Line Coverage	Function Coverage
solx	🟢 83.6%	🔴 20.0%
solx-benchmark-converter	🔴 0.0%	🔴 0.0%
solx-codegen-evm	🔴 25.5%	🔴 13.5%
solx-compiler-downloader	🔴 0.0%	🔴 0.0%
solx-core	🔴 38.6%	🔴 47.4%
solx-dev	🔴 2.4%	🔴 3.0%
solx-evm-assembly	🔴 0.0%	🔴 0.0%
solx-mlir	🟡 59.3%	🟡 55.1%
solx-slang	🔴 23.6%	🔴 34.2%
solx-solc-test-adapter	🔴 1.7%	🔴 2.1%
solx-standard-json	🔴 42.8%	🔴 47.7%
solx-tester	🔴 36.5%	🔴 34.3%
solx-utils	🔴 29.3%	🔴 32.9%
solx-yul	🔴 0.0%	🔴 0.0%
Total	🔴 11.0%	🔴 13.2%

Codecov Report | HTML Report | Workflow Run

[hedgar2017]

Thanks! Looks good, but could you run cargo run-tester-slang and post the test tally? AFAIU, it should have unblocked some stack-too-deep tests?

[abinavpp]

cargo run-tester-slang: 10243 -> 10247 passed (245 -> 241 failed, 474 invalid unchanged, 10962 total).

The delta is one file, tests/solidity/simple/algorithm/arrays/standard_functions_high_order.sol (4 cases). It is exactly the silent case this PR is about: the retry used to re-run codegen with the spill region pinned at 0x80, i.e. under the heap, so the filter/complex calls returned corrupted arrays instead of aborting. Nothing else changes state, and the corpus surfaces no other spilling contract at M3B3.

Measured with the two commits cherry-picked onto main-slang (6387d7e), since the branch as pushed is still main-based, solx-solidity at the pinned submodule commit, and the paired MLIR install from solx-llvm#142.

[abinavpp]

Correction to the tally above, after rebasing the MLIR side onto current main.

Baseline and branch are now identical: 10247 passed / 241 failed / 474 invalid, same failing set - so this PR's tester delta is 0.

The +4 I reported was not this PR. It came from solx-llvm main's [mlir][Sol] Build precise per-type dispatch tables for internal fnptr calls, which my install predated: with that commit, standard_functions_high_order.sol stops spilling altogether and passes on plain main-slang. Measured both ways - it flips on the baseline binary as soon as the install carries that commit.

So the corpus currently contains no test whose outcome depends on the retry path. What the fix buys is still real, just unobservable here: under the pre-dispatch-table MLIR that file was the demonstration (corrupted arrays -> pass), and the hand-written spill inputs behave correctly (reload reuse and the return buffer land at G+S, a non-spilling contract keeps FMP at 0x80). Cost is nil: a sequential sweep of tests/solidity plus the upstream semanticTests (2891 files) shows no systematic compile-time difference.

[hedgar2017]

LGTM, but please get merged LLVM first.