Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do we need to track max_bit_size in Instruction::Truncate? #6998

Open
TomAFrench opened this issue Jan 9, 2025 · 0 comments
Open

Do we need to track max_bit_size in Instruction::Truncate? #6998

TomAFrench opened this issue Jan 9, 2025 · 0 comments

Comments

@TomAFrench
Copy link
Member

Instruction::Truncate compiles down to a euclidean division where max_bit_size is passed in as the bit_size argument. The only place this is used in the circuit are

// maximum bit size for q and for [r and rhs]
let mut max_q_bits = bit_size;
let mut max_rhs_bits = bit_size;
// when rhs is constant, we can better estimate the maximum bit sizes
if let Some(rhs_const) = rhs_expr.to_const() {
max_rhs_bits = rhs_const.num_bits();
if max_rhs_bits != 0 {
if max_rhs_bits > bit_size {
return Ok((zero, zero));
}
max_q_bits = bit_size - max_rhs_bits + 1;
}
}

where we explicitly ignore this if the rhs term of the division is known at compile time (as is the case for truncations), also in

AcirValue::Var(lhs, AcirType::unsigned(bit_size)),
AcirValue::Var(rhs, AcirType::unsigned(bit_size)),

Where we're just specifying the types to be given to the brillig VM (where there's no difference between passing the real bit sizes and fake ones as long as they're big enough)

Brillig ignores max_bit_size entirely.

This raises the question of whether we just remove this field from Instruction::Truncate and pass in 254 as the bit size during ACIR gen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

Successfully merging a pull request may close this issue.

2 participants