Repository navigation
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a985467fae
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| addConversion([this, ctx](array::ArrayType arrType) { | ||
| return smt::ArrayType::get(ctx, smt::IntType::get(ctx), convertType(arrType.getElementType())); | ||
| }); |
There was a problem hiding this comment.
Preserve one SMT array layer per LLZK dimension
For any LLZK array with rank greater than one, this creates only a single SMT array whose range is the scalar element type. smtReadArray nevertheless emits one smt.array.select per index, so a read from !array.type<2,2 x !felt.type> attempts the second select on the !smt.int returned by the first one and produces invalid IR. Construct a nested SMT array type for every LLZK dimension, or flatten the indices consistently.
Useful? React with 👍 / 👎.
| patterns.add<WriteArrayConverter>(converter, context, [](Value) -> ArrayWriteMode { | ||
| return ArrayWriteMode::WriteOnce; |
There was a problem hiding this comment.
Reject arrays that do not satisfy the write-once policy
This policy classifies every array as write-once without performing any analysis. For a valid mutable-array program that writes different values to the same index twice, the lowering emits assertions equating the original SMT array element to both values instead of letting the second write replace the first, silently changing satisfiability. Detect and reject overwrites or implement the Overwrite encoding rather than unconditionally selecting WriteOnce.
Useful? React with 👍 / 👎.
| addConversion([this, ctx](array::ArrayType arrType) { | ||
| return smt::ArrayType::get(ctx, smt::IntType::get(ctx), convertType(arrType.getElementType())); | ||
| }); |
There was a problem hiding this comment.
Avoid converting arrays without patterns in the naive pass
The type converter is shared with SMTNaiveLoweringPass, but that pass does not register ReadArrayConverter, WriteArrayConverter, or IndexConstConverter. Consequently, a naive-lowering input with an array of felts now has its function argument changed to !smt.array while its array.read/array.write operations and index producers remain in their original forms; with materializations disabled, the pass fails or leaves verifier-invalid operands. Either add equivalent array patterns to the naive strategy or scope this conversion to the optimized pass.
Useful? React with 👍 / 👎.
c8bc13c to
a09159b
Compare
10e7c42 to
3ca4d8c
Compare
3ca4d8c to
cd26713
Compare
fb08efb to
341bad9
Compare
4c933e5 to
b5ffc08
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b5ffc08274
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
b5ffc08 to
38b5977
Compare
| // CHECK-NEXT: %[[VAL_44:[0-9a-zA-Z_\.]+]] = arith.constant 0 : index | ||
| // CHECK-NEXT: %[[VAL_45:[0-9a-zA-Z_\.]+]] = arith.constant 1 : index | ||
| // CHECK-NEXT: %[[VAL_46:[0-9a-zA-Z_\.]+]] = arith.constant 8 : index | ||
| // CHECK-NEXT: %[[I0:[0-9a-zA-Z_\.]+]] = smt.int.constant 0 | ||
| // CHECK-NEXT: %[[VAL_44:[0-9a-zA-Z_\.]+]] = builtin.unrealized_conversion_cast %[[I0]] : !smt.int to index | ||
| // CHECK-NEXT: %[[I1:[0-9a-zA-Z_\.]+]] = smt.int.constant 1 | ||
| // CHECK-NEXT: %[[VAL_45:[0-9a-zA-Z_\.]+]] = builtin.unrealized_conversion_cast %[[I1]] : !smt.int to index | ||
| // CHECK-NEXT: %[[I8:[0-9a-zA-Z_\.]+]] = smt.int.constant 8 | ||
| // CHECK-NEXT: %[[VAL_46:[0-9a-zA-Z_\.]+]] = builtin.unrealized_conversion_cast %[[I8]] : !smt.int to index | ||
| // CHECK-NEXT: scf.for %[[VAL_47:[0-9a-zA-Z_\.]+]] = %[[VAL_44]] to %[[VAL_46]] step %[[VAL_45]] { | ||
| // CHECK-NEXT: %[[VAL_48:[0-9a-zA-Z_\.]+]] = array.read %[[VAL_1]]{{\[}}%[[VAL_47]]] : <8 x !felt.type>, !felt.type | ||
| // CHECK-NEXT: %[[VAL_49:[0-9a-zA-Z_\.]+]] = builtin.unrealized_conversion_cast %[[VAL_48]] : !felt.type to !smt.int | ||
| // CHECK-NEXT: %[[VAL_50:[0-9a-zA-Z_\.]+]] = array.read %[[VAL_3]]{{\[}}%[[VAL_47]]] : <8 x !felt.type>, !felt.type | ||
| // CHECK-NEXT: %[[VAL_51:[0-9a-zA-Z_\.]+]] = builtin.unrealized_conversion_cast %[[VAL_50]] : !felt.type to !smt.int | ||
| // CHECK-NEXT: %[[VAL_52:[0-9a-zA-Z_\.]+]] = smt.eq %[[VAL_49]], %[[VAL_51]] : !smt.int | ||
| // CHECK-NEXT: %[[IDX:[0-9a-zA-Z_\.]+]] = builtin.unrealized_conversion_cast %[[VAL_47]] : index to !smt.int | ||
| // CHECK-NEXT: %[[VAL_48:[0-9a-zA-Z_\.]+]] = smt.array.select %[[VAL_0]]{{\[}}%[[IDX]]] : !smt.array<[!smt.int -> !smt.int]> | ||
| // CHECK-NEXT: %[[VAL_50:[0-9a-zA-Z_\.]+]] = smt.array.select %[[VAL_1]]{{\[}}%[[IDX]]] : !smt.array<[!smt.int -> !smt.int]> | ||
| // CHECK-NEXT: %[[VAL_52:[0-9a-zA-Z_\.]+]] = smt.eq %[[VAL_48]], %[[VAL_50]] : !smt.int |
There was a problem hiding this comment.
Does more need to be done about these unrealized_conversion_cast to/from index?
There was a problem hiding this comment.
I'm not sure, but I don't think so? LLEQ (and I'm pretty sure the SMTLIB emitter) know how to see through those, and I think they're only there because scf.for needs the ivar to be an index.
| } | ||
|
|
||
| WriteArrayConverter::WriteArrayConverter( | ||
| mlir::TypeConverter &converter, mlir::MLIRContext *context, ArrayWritePolicy writePolicy, |
437f29d to
838ea69
Compare
No description provided.