Skip to content

Allow engine flags to be specified multiple times - #328

Merged
fitzgen merged 4 commits into
bytecodealliance:mainfrom
fitzgen:engine-flags-multiple-times
Jul 23, 2026
Merged

Allow engine flags to be specified multiple times#328
fitzgen merged 4 commits into
bytecodealliance:mainfrom
fitzgen:engine-flags-multiple-times

Conversation

@fitzgen

@fitzgen fitzgen commented Jul 22, 2026

Copy link
Copy Markdown
Member

Change --engine-flags to accept multiple values and pair them with the engines as follows:

  • A single engine with multiple flag sets is paired with each set

  • Multiple engines with zero or one flag set pairs each engine with the flag set (if any)

  • N engines and N flag sets are paired together by position: engines[i] with flags[i]

  • All other combinations are errors.

This allows, for example, comparing the performance effects of different flags for the same engine, e.g. the DRC vs copying collector:

sightglass-cli benchmark \
    -e engines/wasmtime/libengine.dylib \
    --engine-flags "-Ccollector=copying" \
    --engine-flags "-Ccollector=drc" \
    -- benchmarks/splay/splay.wasm

Change `--engine-flags` to accept multiple values and pair them with the engines
as follows:

- A single engine with multiple flag sets is paired with each set

- Multiple engines with zero or one flag set pairs each engine with the flag
set (if any)

- N engines and N flag sets are paired together by position: `engines[i]` with
  `flags[i]`

- All other combinations are errors.

This allows, for example, comparing the performance effects of different flags
for the same engine, e.g. the DRC vs copying collector:

```
sightglass-cli benchmark \
    -e engines/wasmtime/libengine.dylib \
    --engine-flags "-Ccollector=copying" \
    --engine-flags "-Ccollector=drc" \
    -- benchmarks/splay/splay.wasm
```
@fitzgen
fitzgen requested a review from cfallin July 22, 2026 18:36
@cfallin

cfallin commented Jul 23, 2026

Copy link
Copy Markdown
Member

Thanks for this; the semantics you've described make reasonable sense each in isolation, but I worry that this interface will be too confusing/complex for a user to invoke and have reasonable expectations for. Especially the transparent shift between one-flags-applies-to-all and flags-apply-pairwise is a mistake waiting to happen: forgetting some flag options could switch modes transparently and cause unexpected flags to apply to later engines.

I wonder if we could disambiguate intent with two different flags: --engine-flags-common and --engine-flags. Then there would be two canonical invocation idioms:

  • -e engine1.so --engine-flags flag1 -e engine2.so --engine-flags flag2 ...

    (the arg-parser doesn't enforce the interleaving, but this would be a nice and clear way to write the command line); and

  • -e engine1.so -e engine2.so ... --engine-flags-common universal-flag

What's more, they could also compose, which might be really useful: specify common flags once, but also add flags to each run individually.

This seems to me to be a minor change to your logic, and overall simplifies the semantics / makes them more understandable. What do you think?

@fitzgen

fitzgen commented Jul 23, 2026

Copy link
Copy Markdown
Member Author

This seems to me to be a minor change to your logic, and overall simplifies the semantics / makes them more understandable. What do you think?

I like this, will implement it shortly

@fitzgen

fitzgen commented Jul 23, 2026

Copy link
Copy Markdown
Member Author

@cfallin ready for re-review!

@cfallin cfallin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

👍

@fitzgen
fitzgen merged commit e8870c1 into bytecodealliance:main Jul 23, 2026
12 checks passed
@fitzgen
fitzgen deleted the engine-flags-multiple-times branch July 23, 2026 18:35
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.

2 participants