Support level reduction interface for multiple secret operands - #3324
Merged
Conversation
copybara-service
Bot
force-pushed
the
test_962185352
branch
2 times, most recently
from
August 10, 2026 17:08
c18ec95 to
1bb8df9
Compare
copybara-service
Bot
changed the title
copybara-service
Bot
force-pushed
the
test_962185352
branch
2 times, most recently
from
August 10, 2026 19:12
280ca75 to
aa3e7c4
Compare
mdgrs
reviewed
Aug 10, 2026
| linalg::Conv1DNcwFcwOp::attachInterface< | ||
| LinalgReducesLevelOpInterfaceModel<linalg::Conv1DNcwFcwOp>>(*ctx); | ||
| linalg::Conv2DNhwcFhwcOp::attachInterface< | ||
| LinalgReducesLevelOpInterfaceModel<linalg::Conv2DNhwcFhwcOp>>(*ctx); |
Collaborator
There was a problem hiding this comment.
The one that we work with in ConvertToCiphertextSemanctics and LayoutPropagation is instead NchwFchw. Why is this the conv2d that is registered?
| levelVal = level.getInt(); | ||
| } else if (level.isMaxLevel()) { | ||
| levelVal = levelBudget; | ||
| } else { |
Collaborator
There was a problem hiding this comment.
What if it is Uninit or Invalid? is it right to continue, or should a bootstrap be added?
Collaborator
There was a problem hiding this comment.
I think both of these should trigger an error.
| SmallVector<OpOperand*> getOperandsToReduce( | ||
| Operation* op, const DataFlowSolver* solver) const { | ||
| SmallVector<OpOperand*> result; | ||
| for (auto& operand : op->getOpOperands()) { |
Collaborator
There was a problem hiding this comment.
I don't know much about this, but my untrusty sidekick tells me that we should use getDpsInputOperands to avoid the outs accumulator that getOpOperands includes in the output
Collaborator
There was a problem hiding this comment.
You're right, but I think we only want to avoid the outs accumulator because we know that these ops will not reduce the level of the outs.
copybara-service
Bot
force-pushed
the
test_962185352
branch
3 times, most recently
from
August 10, 2026 23:39
226c98f to
2a731fa
Compare
This is intended to support an eager (greedy) bootstrap placement pass earlier in the pipeline, by treating linalg ops and polynomial evaluation ops all as atomic, ensuring bootstraps aren't inserted mid-loop. To support that, we need to know at level analysis time which of the (potentially multiple) operands of a linalg op are secret. For ops like ct-ct mul, this is a hard requirement, and for ops like matvec, we have seen cases where the vector or the matrix can be secret while the other is plaintext. PiperOrigin-RevId: 962442140
copybara-service
Bot
force-pushed
the
test_962185352
branch
from
August 10, 2026 23:53
2a731fa to
b5fd466
Compare
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
2 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.
Support level reduction interface for multiple secret operands
This is intended to support an eager (greedy) bootstrap placement pass earlier in the pipeline, by treating linalg ops and polynomial evaluation ops all as atomic, ensuring bootstraps aren't inserted mid-loop.
To support that, we need to know at level analysis time which of the (potentially multiple) operands of a linalg op are secret. For ops like ct-ct mul, this is a hard requirement, and for ops like matvec, we have seen cases where the vector or the matrix can be secret while the other is plaintext.