Removed mod_arith::ExtractOp#3094
Merged
copybara-service[bot] merged 1 commit intoJun 17, 2026
Merged
Conversation
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
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.
Removed
mod_arith::ExtractOpin favor of the newmod_arith::LiftOp. This turned out to be more work than anticipated.The expected changes:
LiftOpinstead ofExtractOpConvertExtractfrom ModArithToArithExtractOp:liftinstead ofextractTangentially related changes:
computeMixedRadixCoeffsand lowering forConvertBasisOpuse scf:ForOp loops instead of C++ to reduce IR size/compile time. Note that in both cases, types change in the outer loop, so the outer loop cannot be implemented as an MLIR loop.mod_arith::ExtractOp); it is now much simpler.LiftOp; it is implicit.Unexpected changes:
ExtractOpis not exactly a subset ofLiftOp. For ModArith, you could view it that way (except that ExtractOp might not have output a canonical representative, while LiftOp always does). For RNS, they have different meanings:ExtractOpwould output the tensor of extracted ModArith coeffs.LiftOpdoesn't support RNS for now, but if it did, it would do a CRT reconstruction on the coefficients and output a scalar. This affected a couple of tests, but mostly the lowering ofpolynomial.mul_scalar, which does some fancy unpacking and repacking of the coefficients. SinceLiftOpdoesn't support RNS, I added a special path when multiplying a polynomial by an RNS scalar that avoids it. For the non-RNS case, I changedmod_arith::ExtractOptomod_arith::LiftOp standard; the representative doesn't matter since we immediately re-encapsulate. The representative only matters in "mathematical" code; there the "lifting" is for the compiler's benefit. The same holds in a few other places whereLiftOpreplacedExtractOp.mul_scalarnecessitated this change.Misc changes:
Tests:
mod_arith.extracton RNS, since there is no analog anymore