fix(lowering): normalize storage_base_address_from_felt252 const folding - #10210
Conversation
Const folding rewrote `storage_base_address_from_felt252(c)` into `storage_base_address_const::<c>` using the raw felt value, but the runtime libfunc normalizes the address into `[0, 2**251 - 256)` (subtracting the bound for values at or above it, see sierra-to-casm storage.rs). `storage_base_address_const` rejects out-of-range arguments at Sierra specialization, so folding a valid const in `[2**251 - 256, PRIME)` — e.g. any negative felt, whose canonical value is near PRIME — turned a running program into a compile error. Perform the same normalization on the folded value. The math is done in `Felt252` (canonicalizing the input and avoiding extra `BigInt` allocations), converting to `BigInt` once at the end.
|
This change is |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
PR SummaryMedium Risk Overview When folding a constant input, the pass now applies the same rule as execution: if the value is ≥ Adds optimizer test coverage StorageBaseAddress const normalization with six inputs (small values, boundary cases, and negatives) asserting the expected Reviewed by Cursor Bugbot for commit 1e91c0d. Bugbot is set up for automated code reviews on this repo. Configure here. |
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:
Summary
During const folding of
storage_base_address_from_felt252, the inputfelt252value is now normalized before being embedded as astorage_base_address_constgeneric argument. Values at or above0x7ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00are reduced by that bound, matching the runtime behavior ofstorage_base_address_from_felt252.Type of change
Please check one:
Why is this change needed?
storage_base_address_from_felt252clamps its input at runtime: values in the high range (≥ADDR_BOUND) are wrapped by subtractingADDR_BOUND. The const folding optimization was previously passing the rawfelt252value directly intostorage_base_address_constwithout applying this normalization, producing a different constant than what the runtime would compute. For example,-1as afelt252would fold to an incorrect address instead of the expected normalized value.What was the behavior or documentation before?
When
storage_base_address_from_felt252was called with a constantfelt252value ≥ADDR_BOUND(including negative values like-1and-2), the const folding pass emittedstorage_base_address_constwith the raw, un-normalized value, diverging from the runtime result.What is the behavior or documentation after?
The const folding pass now applies the same normalization as the runtime: if the
felt252value is ≥ADDR_BOUND, it subtractsADDR_BOUNDbefore constructing the constant. For example,-1now correctly folds tostorage_base_address_const::<106710729501573572985208420194530329073740042555888586719488>().Related issue or discussion (if any)
Additional context
A new test case (
StorageBaseAddress const normalization) covers the six cases: small positive values (unchanged), a value just belowADDR_BOUND(unchanged), a value atADDR_BOUND(normalized to255), a value just belowADDR_BOUNDthat is not normalized, and-1/-2(normalized to their correct addresses).