PoC for two passes of pilopt

[qwang98]

After discussing with @Schaeff, we plan to have two pilopt passes, one before "backend aware tuning" and one after. In a chronological order:

1. Linker will emit native bus interactions only.
2. Pil analyzer
3. First pass pilopt (potentially insert optimization for connections)
4. (Optional) backend aware tuning: only executed if a backend argument is provided. For backends that can process native bus interactions (e.g. Stwo), directly send it down the pipeline without modification. For backends that can't, call multi_bus_linker, which creates bus columns/constraints and phantom bus interaction.
5. (Optional) second pass pilopt, executed only if step 4 is run.

I do have one question:

1. Will there be cases where the backend argument is not provided but a "default backend" which requires phantom bus interaction is still run? In this edge case, step 4 and 5 will not emit phantom bus interaction but the "default backend" still demands it. If this can happen, then this PR won't work. The fix would be simple though: just instantiate the default BackendFactory and call backend aware tuning on it.

[qwang98]

This will be an API for BackendFactory instead of Backend, because constructing Backend requires input witness etc., which aren't yet known at this point. BackendFactory is tied to the command line backend argument, which is appropriate for backend aware tuning which this API will include in the future.

[Schaeff]

That makes sense I think!

[qwang98]

If no backend argument is provided in the pipeline, this will simply return the same PIL (one pilopt pass instead of two).

[chriseth]

I'm wondering if it would make sense to make this a separate pipeline step / artefact

[qwang98]

I'm wondering if it would make sense to make this a separate pipeline step / artefact

I also discussed this with @Schaeff and sounds good to us. :)

[qwang98]

This new version is also a PoC and will fail tests. The work flow is: pilopt -> backend specific tuning -> pilopt -> witgen and etc. In this design, compute_witness (stage 0 witgen) will require knowing the backend type (there are stage 0 bus columns to generate for some backend types but not other types). This requirement is enforced by calling compute_backend_tuned_pil in compute_witness. However, this creates a new problem: many benchmarking/testing functions runs all the way till right before the backend. Previously, backend type is not required as stage 0 witgen is the same for all backends. Now, we would have to specify a backend type for these benchmarking/testing functions. I propose two solutions to address this:

1. Default these benchmarking/testing functions to a backend type that requires stage 0 bus column witgen. This will be a "conservative" estimate of our benchmarks, because it has longer witgen than backends that use native bus interaction.
2. Move bus witgen to the backend and run it as the first step of the backend. This removes the need for two passes of pilopt, because all "backend specific tuning" are now in the backend itself.

P.S. I made comments throughout the PR to mark these scenarios (which a lot more complicated than described above), so you can get a sense of the various cases we encounter here.