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

feat: location tree for debug_info #7034

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

feat: location tree for debug_info #7034

wants to merge 19 commits into from

Conversation

guipublic
Copy link
Contributor

Description

Problem*

Resolves #6946

Summary*

Adds the location tree to debug info and reference call-stacks through their 'index' in the tree (i.e a node of the tree).

Additional Context

The location tree is merged from ACIR location tree and brillig per function location trees.
The PR is a draft because it does not merge the trees in case of several ACIR functions, and also one flame graph test is failing in Noir debugger.

Documentation*

Check one:

  • No documentation needed.
  • Documentation included in this PR.
  • [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

  • I have tested the changes locally.
  • I have formatted the changes with Prettier and/or cargo fmt on default settings.

Copy link
Contributor

github-actions bot commented Jan 13, 2025

Compilation Memory Report

Program Peak Memory %
keccak256 77.63M 0%
workspace 123.94M 0%
regression_4709 424.14M 0%
ram_blowup_regression 1.46G 0%
rollup-root 597.10M 77%
rollup-merge 493.80M 115%
rollup-block-root-single-tx 16.05G 6%
rollup-block-root-empty 487.97M 118%
rollup-block-root 16.06G 6%
rollup-block-merge 597.09M 77%
rollup-base-public 2.33G 0%
rollup-base-private 1.11G 100%
private-kernel-tail 206.15M -1%
private-kernel-reset 567.56M -3%
private-kernel-inner 293.62M -1%

Copy link
Contributor

github-actions bot commented Jan 13, 2025

Execution Memory Report

Program Peak Memory %
keccak256 74.68M 0%
workspace 123.97M 0%
regression_4709 316.00M 0%
ram_blowup_regression 512.46M 0%
rollup-root 494.81M 114%
rollup-merge 472.73M 130%
rollup-block-root 1.08G 0%
rollup-block-merge 494.82M 114%
rollup-base-public 667.94M 39%
rollup-base-private 562.61M 73%
private-kernel-tail 179.42M -1%
private-kernel-reset 228.64M -7%
private-kernel-inner 203.62M -3%

Copy link
Contributor

github-actions bot commented Jan 14, 2025

Execution Report

Program Execution Time %
sha256_regression 0.051s 0%
regression_4709 0.001s 0%
ram_blowup_regression 0.620s 3%
rollup-root 0.104s 0%
rollup-merge 0.007s 16%
rollup-block-root 37.300s 1%
rollup-block-merge 0.104s -3%
rollup-base-public 1.220s -1%
rollup-base-private 0.453s 0%
private-kernel-tail 0.019s 0%
private-kernel-reset 0.314s 0%
private-kernel-inner 0.070s 4%

Copy link
Contributor

github-actions bot commented Jan 14, 2025

Compilation Report

Program Compilation Time %
sha256_regression 1.020s -5%
regression_4709 0.809s -1%
ram_blowup_regression 16.000s -2%
rollup-root 3.534s 5%
rollup-merge 2.060s 6%
rollup-block-root-single-tx 140.000s 0%
rollup-block-root-empty 2.028s 3%
rollup-block-root 138.000s -7%
rollup-block-merge 3.644s 8%
rollup-base-public 26.520s -8%
rollup-base-private 9.696s -3%
private-kernel-tail 0.956s 2%
private-kernel-reset 5.890s -4%
private-kernel-inner 2.228s 11%

@TomAFrench
Copy link
Member

Merging in master to compare artifact sizes in aztec-packages.

@TomAFrench
Copy link
Member

Nice, this drops the artifact size of rollup-block-root-single-tx by ~1MB from 20 to 19. Compilation time drops by 50s

@guipublic guipublic marked this pull request as ready for review January 14, 2025 18:04
@guipublic guipublic requested a review from a team January 14, 2025 18:11
Copy link
Member

@TomAFrench TomAFrench left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to hit send on these comments.

Also aztec-packages has their own homebrew method of dealing with debug info in their simulator which is this is definitely going to break. Can you take a look at what this will take to update?

compiler/noirc_evaluator/src/ssa/opt/unrolling.rs Outdated Show resolved Hide resolved
compiler/noirc_errors/src/call_stack.rs Outdated Show resolved Hide resolved
tooling/debugger/src/context.rs Outdated Show resolved Hide resolved
compiler/noirc_evaluator/src/brillig/mod.rs Outdated Show resolved Hide resolved
Comment on lines +101 to +108
pub brillig_locations:
BTreeMap<BrilligFunctionId, BTreeMap<BrilligOpcodeLocation, CallStackId>>,
pub location_tree: LocationTree,
/// Map opcode index of an ACIR circuit into the source code location
/// Serde does not support mapping keys being enums for json, so we indicate
/// that they should be serialized to/from strings.
#[serde_as(as = "BTreeMap<DisplayFromStr, _>")]
pub locations: BTreeMap<OpcodeLocation, Vec<Location>>,
pub brillig_locations:
BTreeMap<BrilligFunctionId, BTreeMap<BrilligOpcodeLocation, Vec<Location>>>,
pub location_map: BTreeMap<OpcodeLocation, CallStackId>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you give an explainer on how exactly these fit together? I'm thinking that we're storing unnecessary data in location_map now.

My understanding is that:

  • brillig_locations stores for each brillig function a mapping from each opcode index to a callstack id
  • We can then use this and then look up the callstack id in location_tree to get the associate callstack for any brillig opcode.
  • location_map stores a mapping from (acir_opcode_index, brillig_index) to a callstack id which we can use with location_tree.

Why do we need to track (acir_opcode_index, brillig_index) in location_map now? If we fail inside of a brillig call we can tell which brillig function we're executing from the ACIR opcode we've halted on, we then

  1. Get the callstack for the ACIR opcode in which we make the call
  2. Check the brillig opcode within that call we halted on and get the relevant callstack for the unconstrained function.
  3. Smoosh these two together to generate the final callstack.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory this makes sense, in practice I don't see where those brillig locations are inserted in the location_map.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, true we seem to have removed the insertion of any OpcodeLocation::Brillig a while back.

It still stands that we don't need to keep this enum in the build artifact anymore though as it's currently tech debt. We've kept this enum around just to keep the program serialization format the same but as we're changing it now anyway, now's a good time to clear up this tech debt.

#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash, PartialOrd, Ord, Serialize, Deserialize)]
/// Opcodes are locatable so that callers can
/// map opcodes to debug information related to their context.
pub enum OpcodeLocation {
Acir(usize),
// TODO(https://github.com/noir-lang/noir/issues/5792): We can not get rid of this enum field entirely just yet as this format is still
// used for resolving assert messages which is a breaking serialization change.
Brillig { acir_index: usize, brillig_index: usize },
}

#5792

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

Successfully merging this pull request may close these issues.

Reduce memory footprint of artifact debug info
2 participants