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

Flattening and remove ifelse adds instructions with empty call stacks #5322

Closed
sirasistant opened this issue Jun 25, 2024 · 0 comments · Fixed by #5697
Closed

Flattening and remove ifelse adds instructions with empty call stacks #5322

sirasistant opened this issue Jun 25, 2024 · 0 comments · Fixed by #5697
Labels
bug Something isn't working

Comments

@sirasistant
Copy link
Contributor

sirasistant commented Jun 25, 2024

Aim

Profiling where all the constraints in the program come from

Expected Behavior

Every ACIR opcode should have a call stack associated with it

Bug

Some ACIR opcodes in the program have no call stack associated. I've added a condition in the SSA printer to figure out wich instructions in SSA do not have any call stack associated.

I've tracked down these instructions to some optimization steps:

  • flatten_cfg.rs: Explicitely uses CallStack::new() for instructions related with the if condition. A solution to this might be to add call_stack to JmpIf in the same way Jmp and Return have call stacks, to associated the emitted instructions with.
  • value_merger.rs::merge_numeric_values: This seems to be emitting some Cast and mul instructions with no call stack associated, because sometimes the if value and the else value have no call stack associated. I guess this can happen when the if else values don't come from previous instructions, such as being block params or constants
  • remove_if_else.rs: Seems to be emitting array_get instructions with no call_stack, presumably from value_merger::merge_array_values that has a explicit CallStack::new() when emitting an ArrayGet

In the case we can't track down the instructions to a specific location instruction, it'd be good to at least use the call stack of the function being processed, allowing users to at least track that the instruction comes from a given function call, even though they might not know which part of the function being called generated it 🤔

To Reproduce

Modify this code in printer.rs

/// Display an arbitrary instruction
pub(crate) fn display_instruction(
    function: &Function,
    instruction: InstructionId,
    f: &mut Formatter,
) -> Result {
    // instructions are always indented within a function
    write!(f, "    ")?;

    let results = function.dfg.instruction_results(instruction);
    if !results.is_empty() {
        write!(f, "{} = ", value_list(function, results))?;
    }

    display_instruction_inner(function, &function.dfg[instruction], f, instruction)
}

fn display_instruction_inner(
    function: &Function,
    instruction: &Instruction,
    f: &mut Formatter,
    instruction_id: InstructionId,
) -> Result {
    let show = |id| value(function, id);

    let call_stack = function.dfg.get_call_stack(instruction_id);

    if call_stack.is_empty() {
        write!(f, "NO CALL STACK ")?;
    }

And compile a large program such as aztec protocol circuits or the token contract transfer function with show ssa enabled.

Project Impact

None

Impact Context

No response

Workaround

None

Workaround Description

No response

Additional Context

No response

Installation Method

None

Nargo Version

No response

NoirJS Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@sirasistant sirasistant added the bug Something isn't working label Jun 25, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Jun 25, 2024
github-merge-queue bot pushed a commit that referenced this issue Aug 8, 2024
# Description

## Problem\*

Resolves #5322

## Summary\*

Previously we added call stacks as a way to give better error reporting
on SSA instructions. Since these were just for errors, they only needed
to be on instructions which could emit errors. Since then, these call
stacks have also been used for profiling Noir code which revealed many
instructions without locations - many of them being instructions
inserted by the compiler rather than the user during intermediate
compiler passes like flatten_cfg.

I've went through and gotten rid of each case of `CallStack::new()`. As
far as I can tell all the remaining locations are either the intended
use case of an initial, empty value, or are used in some error messages
where the location is unknown.

Anyways - because many of the instructions without locations were not
introduced by the user I've had to decide which location best describes
them. These instructions are largely internal compiler details so many
users would be surprised if they knew e.g. we inserted extra `Store`
instructions to _undo_ previous store instructions when going between an
if expression's then and else branches. In this case, I set the location
of this undo store instruction the same as the original store, but an
argument could be made that it should actually be in the else branch or
share location with the whole if expression. Similarly, when an `if`
expression is used we merge the return value of the then & else branches
to get the return value of the `if` expression itself. For these values
I've opted to use the location of the entire `if` expression.

## Additional Context

@vezenovm I think this covers all the work needed for this issue after
all.

## Documentation\*

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist\*

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
github-merge-queue bot pushed a commit that referenced this issue Aug 8, 2024
# Description

## Problem\*

Resolves #5322

## Summary\*

Previously we added call stacks as a way to give better error reporting
on SSA instructions. Since these were just for errors, they only needed
to be on instructions which could emit errors. Since then, these call
stacks have also been used for profiling Noir code which revealed many
instructions without locations - many of them being instructions
inserted by the compiler rather than the user during intermediate
compiler passes like flatten_cfg.

I've went through and gotten rid of each case of `CallStack::new()`. As
far as I can tell all the remaining locations are either the intended
use case of an initial, empty value, or are used in some error messages
where the location is unknown.

Anyways - because many of the instructions without locations were not
introduced by the user I've had to decide which location best describes
them. These instructions are largely internal compiler details so many
users would be surprised if they knew e.g. we inserted extra `Store`
instructions to _undo_ previous store instructions when going between an
if expression's then and else branches. In this case, I set the location
of this undo store instruction the same as the original store, but an
argument could be made that it should actually be in the else branch or
share location with the whole if expression. Similarly, when an `if`
expression is used we merge the return value of the then & else branches
to get the return value of the `if` expression itself. For these values
I've opted to use the location of the entire `if` expression.

## Additional Context

@vezenovm I think this covers all the work needed for this issue after
all.

## Documentation\*

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist\*

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Aug 8, 2024
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
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant