Criterion's benchmark grouping does not match on group names; it only
groups benchmarks that are run prior to that specific benchmark group
instance being dropped. Since each benchmark group holds a mutable
reference to the criterion instance, this means we can't have multiple
active groups collecting measurements. Instead, we need to collect the
proving benchmarks for all recipient numbers, followed by verification
benchmarks.
The ECC test chip performs various checks that assume the chip will only
be synthesized with witnesses. This assumption is broken by the chip
printer test, so we fix the assumption here.
In order to make the changeover easier to review, we redefined
`CellValue<F>` to be `AssignedCell<F, F>`. Now we remove that type and
rename throughout the codebase.
As the underlying `Region` methods now return `AssignedCell` instead of
`Cell`, we can simplify all the places where we then constructed a
`CellValue` struct.
We change `CellValue` into a typedef of `AssignedCell` to simplify the
migration in this commit.
The migration from `CellValue` to `AssignedCell` requires several other
changes:
- `<CellValue as Var>::value()` returned `Option<F>`, whereas
`AssignedCell::<F, F>::value()` returns `Option<&F>`. This means we
need to dereference, use `Option::cloned`, or alter functions to take
`&F` arguments.
- `StateWord` in the Poseidon chip has been changed to a newtype around
`AssignedCell` (the chip was written before `CellValue` existed).
This is only used in chip::mul::Config. In a subsequent commit,
this will be configured from mul::Config instead of from
ecc::chip::Config.
This commit does not result in circuit changes.
This is only used in chip::mul::Config. In a subsequent commit,
this will be configured from mul::Config instead of from
ecc::chip::Config.
This commit does not result in circuit changes.
This is only used in chip::mul::Config. In a subsequent commit,
this will be configured from mul::Config instead of from
ecc::chip::Config.
This commit does not result in circuit changes.
We are about to extract the sub-configs from mul::Config and refactor
them. Doing so would have moved their gate definitions past the one gate
that isn't created in a sub-config. Reordering the definitions here will
make the subsequent refactor diffs simpler to review.