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

operator ordering changes number of ACIR opcodes #5290

Closed
zac-williamson opened this issue Jun 19, 2024 · 3 comments
Closed

operator ordering changes number of ACIR opcodes #5290

zac-williamson opened this issue Jun 19, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@zac-williamson
Copy link

Aim

When defining a multiplication, I noticed that the location of a negative sign changed the number of ACIR opcodes. An unneccessary expression is created that simply multiplies a witness by a constant.

Expected Behavior

I expect both versions of the add function (see Bug description) to produce 7 ACIR opcodes. However the second version produces 8 ACIR opcodes due to the unneccessary constraint that is added to negate \lambda

Bug

See how changing the location of the - sign on line 31 changes the compiled ACIR.

image image

To Reproduce

  1. clone git@github.com:zac-williamson/noir-edwards.git
  2. run nargo info
  3. in curve.nr, modify line 31 to be let y_lhs = y * lambda * -d + y + x1x2;
  4. run nargo info, observe ACIR constraint count has decreased

Project Impact

None

Impact Context

No response

Workaround

Yes

Workaround Description

Keep fiddling with operator ordering until something works. Rather annoying though.

Additional Context

No response

Installation Method

Binary (noirup default)

Nargo Version

nargo version 0.23

NoirJS Version

0.23

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@zac-williamson zac-williamson added the bug Something isn't working label Jun 19, 2024
@TomAFrench
Copy link
Member

My guess on this is that the negation of lambda results in us turning a the AcirVarData::Witness for lambda into an AcirVarData::Expr for -lambda, this probably then results in us going down a different codepath for the later multiplications resulting in worse codegen.

Staring at the mul_var method in acir_gen will probably solve this.

@TomAFrench
Copy link
Member

On the latest nightly I get 7 opcodes per iteration on both versions.

@TomAFrench TomAFrench self-assigned this Jun 20, 2024
@TomAFrench
Copy link
Member

I'm going to close this issue as it seems to be addressed in master. I know you were working on an older version of nargo yesterday so maybe it's something we fixed in the past?

In any case, feel free to reopen if you can reproduce this on the nightly version of nargo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

No branches or pull requests

2 participants