Basic Support for Channels - #410
Draft
shankarapailoor wants to merge 2 commits into
Draft
Conversation
Contributor
iangneal
reviewed
Apr 20, 2026
Comment on lines
+1
to
+3
| # This is a template that lists the available options when creating a changelog entry file | ||
| # Edit according to your changes, before marking a PR as ready for review. | ||
|
|
Contributor
There was a problem hiding this comment.
Suggested change
| # This is a template that lists the available options when creating a changelog entry file | |
| # Edit according to your changes, before marking a PR as ready for review. |
| // | ||
| // Part of the LLZK Project, under the Apache License v2.0. | ||
| // See LICENSE.txt for license information. | ||
| // Copyright 2025 Veridise Inc. |
Contributor
There was a problem hiding this comment.
Suggested change
| // Copyright 2025 Veridise Inc. | |
| // Copyright 2026 Project LLZK |
Applies throughout, I won't make this comment on every location where this change applies.
| The payload signature is declared explicitly on the channel definition. In | ||
| this task, the signature is a builtin tuple type whose elements are all | ||
| `!felt.type`. Multiplicity is not part of the declaration; it remains a | ||
| per-use operand on `channel.push` and `channel.pull`. |
Contributor
There was a problem hiding this comment.
Some of this is repeated from the dialect description.
| equality constraints across interacting LLZK structs. A channel represents | ||
| an unordered multiset of row-local tuples rather than an ordered stream. | ||
| The payload signature is declared explicitly on the channel definition. In | ||
| this task, the signature is a builtin tuple type whose elements are all |
Contributor
There was a problem hiding this comment.
"In this task" sounds odd.
| class ChannelUseOpBase<string mnemonic, list<Trait> traits = []> | ||
| : ChannelDialectOp< | ||
| mnemonic, traits#[AttrSizedOperandSegments, ConstraintGen, | ||
| DeclareOpInterfaceMethods<SymbolUserOpInterface>]> { |
Contributor
There was a problem hiding this comment.
We might want to consider these to be memory-modifying ops with a memory effects trait.
Comment on lines
+81
to
+90
| if (!rhs.tableOffset) { | ||
| return success(); | ||
| } | ||
| if (!lhs.tableOffset) { | ||
| lhs = rhs; | ||
| return success(); | ||
| } | ||
| if (lhs == rhs) { | ||
| return success(); | ||
| } |
Contributor
There was a problem hiding this comment.
Suggested change
| if (!rhs.tableOffset) { | |
| return success(); | |
| } | |
| if (!lhs.tableOffset) { | |
| lhs = rhs; | |
| return success(); | |
| } | |
| if (lhs == rhs) { | |
| return success(); | |
| } | |
| if (!rhs.tableOffset || lhs == rhs) { | |
| return success(); | |
| } | |
| if (!lhs.tableOffset) { | |
| lhs = rhs; | |
| return success(); | |
| } |
Comment on lines
+130
to
+137
| if (!rhs) { | ||
| out = lhs; | ||
| return success(); | ||
| } | ||
| if (*lhs == *rhs) { | ||
| out = lhs; | ||
| return success(); | ||
| } |
Contributor
There was a problem hiding this comment.
Suggested change
| if (!rhs) { | |
| out = lhs; | |
| return success(); | |
| } | |
| if (*lhs == *rhs) { | |
| out = lhs; | |
| return success(); | |
| } | |
| if (!rhs || *lhs == *rhs) { | |
| out = lhs; | |
| return success(); | |
| } |
tim-hoffman
requested changes
Jun 9, 2026
| ``` | ||
| }]; | ||
|
|
||
| let arguments = (ins SymbolNameAttr:$sym_name, TypeAttr:$message_type); |
Member
There was a problem hiding this comment.
Try TypeAttrOf<TupleOf<[LLZK_FeltType]> to get automatic verification
Member
There was a problem hiding this comment.
Alternatively, since it must be a tuple of felt, maybe the channel def could just specify an IndexAttr to denote the size of the tuple and reduce IR verbosity
| mnemonic, traits#[AttrSizedOperandSegments, ConstraintGen, | ||
| DeclareOpInterfaceMethods<SymbolUserOpInterface>]> { | ||
| let arguments = (ins FlatSymbolRefAttr:$channel_ref, | ||
| Variadic<AnyLLZKType>:$tuple, Optional<AnyLLZKType>:$mult); |
Member
There was a problem hiding this comment.
Based on your impl of the channel def and manually implemented verifier for mult I think these should both specify just felt type values are allowed.
Suggested change
| Variadic<AnyLLZKType>:$tuple, Optional<AnyLLZKType>:$mult); | |
| Variadic<LLZK_FeltType>:$tuple, Optional<LLZK_FeltType>:$mult); |
Comment on lines
+84
to
+85
| // expected-error@+1 {{'channel.push' op only valid within a 'function.def' with 'function.allow_constraint' attribute}} | ||
| channel.push @c (%x) : !felt.type |
Member
There was a problem hiding this comment.
add same test for pull as well
| function.def @emit(%a: !struct.type<@RowA>, %b: !struct.type<@RowB>) attributes {function.allow_constraint} { | ||
| %x = struct.readm %a[@x] : !struct.type<@RowA>, !felt.type | ||
| %y = struct.readm %b[@y] : !struct.type<@RowB>, !felt.type | ||
| // expected-error@+1 {{'channel.push' op tuple operands must be derived from a single row context}} |
Member
There was a problem hiding this comment.
What is "row context", a struct? Error message could be more helpful if in terms of LLZK concepts.
| DeclareOpInterfaceMethods<SymbolUserOpInterface>]> { | ||
| let arguments = (ins FlatSymbolRefAttr:$channel_ref, | ||
| Variadic<AnyLLZKType>:$tuple, Optional<AnyLLZKType>:$mult); | ||
| let hasCustomAssemblyFormat = 1; |
Member
There was a problem hiding this comment.
why did let assemblyFormat = not work for these ops?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This draft PR adds initial IR support for channels as a new
channeldialect in the LLZK dialect family.Channels model unordered multiset-equality constraints for cross-struct / cross-chip interaction. This PR introduces the IR surface, parser/printer support, and verifier checks needed to represent channel interactions in LLZK. It does not implement backend lowering or the global multiset balance check.
What This PR Adds
channeldialect with:channel.defchannel.pushchannel.pullchannel.def!felt.typechannel.push/channel.pullas symbol-user ops with:function.allow_constraintDesign Notes
channeldialect, not as ops inside thellzkdialect.channel.defnow carries an explicit payload signature instead of inferring schema from use sites.channel.push/channel.pull; it is not part of the channel declaration.struct.readm,array.read, and field-nativefelt.add/felt.sub/felt.mul/felt.negOpen Questions