feat: add cycle estimation flag for valgrind

[not-matthias]

No description provided.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 7 untouched benchmarks

---

_{Comparing cod-2842-runner-enable-cycle-estimation-for-valgrind (40db78c) with main (2533b0c)}

[greptile-apps]

Greptile Summary

This PR adds a --cycle-estimation experimental CLI flag (and CODSPEED_CYCLE_ESTIMATION env var) that passes --cycle-estimation=yes to Valgrind/Callgrind during simulation-mode benchmark runs, mirroring the existing --experimental-fair-sched pattern end-to-end.

• ExperimentalArgs gains a cycle_estimation: bool field that is propagated through OrchestratorConfig → ExecutorConfig → get_valgrind_args.
• The new flag uses clap::ArgAction::Set, which requires an explicit =true/=false value on the CLI, unlike the sibling --experimental-fair-sched which is a bare presence toggle — this inconsistency will cause a parse error for users who just pass --cycle-estimation.
• --cycle-estimation=yes is inserted into the shared args vector before the tool-selection match, so it will also be forwarded to Valgrind when Tracegrind (not Callgrind) is active.

Confidence Score: 3/5

The core wiring is correct, but ArgAction::Set breaks the flag's advertised usage: passing --cycle-estimation without a value will produce a clap parse error rather than enabling the feature.

The ArgAction::Set choice means the new experimental flag cannot be used in the natural way (--cycle-estimation alone) that every other bool flag in this codebase supports. A user who follows the sibling flag's example and issues --cycle-estimation will receive a hard parse error with no clear guidance. The Tracegrind/cycle-estimation combination is a narrower concern since Tracegrind is already gated as experimental, but the CLI usability defect affects all users of the new flag.

src/cli/experimental.rs — the action = clap::ArgAction::Set on the new cycle_estimation field needs to be removed or changed to SetTrue before the flag is usable.

Important Files Changed

Filename	Overview
src/cli/experimental.rs	Adds cycle_estimation bool flag with ArgAction::Set, which requires an explicit =true/=false value; inconsistent with the sibling experimental_fair_sched flag that acts as a bare presence toggle.
src/executor/valgrind/measure.rs	Appends --cycle-estimation=yes before the tool-selection match, so it is passed unconditionally to both Callgrind and Tracegrind; Callgrind-specific arg should be scoped to the Callgrind arm.
src/executor/config.rs	Adds cycle_estimation: bool to both OrchestratorConfig and ExecutorConfig, propagates it correctly through executor_config_for_command, and initialises it to false in the test helper and default config.
src/cli/exec/mod.rs	Forwards cycle_estimation from ExperimentalArgs to OrchestratorConfig; mechanical change mirrors the existing fair_sched wiring.
src/cli/run/mod.rs	Mirrors exec/mod.rs: wires cycle_estimation into OrchestratorConfig and initialises the field to false in RunArgs::test().

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    CLI["CLI args / env\n--cycle-estimation\nCODSPEED_CYCLE_ESTIMATION"] --> EA["ExperimentalArgs\n.cycle_estimation: bool"]
    EA --> OC["OrchestratorConfig\n.cycle_estimation: bool"]
    OC -->|executor_config_for_command| EC["ExecutorConfig\n.cycle_estimation: bool"]
    EC --> GVA["get_valgrind_args()"]
    GVA -->|"if config.cycle_estimation"| ARG["--cycle-estimation=yes\n(added to args vec)"]
    ARG --> TOOL{SimulationTool?}
    TOOL -->|Callgrind| CG["--tool=callgrind\n(valid ✓)"]
    TOOL -->|Tracegrind| TG["--tool=tracegrind\n(may reject unknown flag ⚠)"]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    CLI["CLI args / env\n--cycle-estimation\nCODSPEED_CYCLE_ESTIMATION"] --> EA["ExperimentalArgs\n.cycle_estimation: bool"]
    EA --> OC["OrchestratorConfig\n.cycle_estimation: bool"]
    OC -->|executor_config_for_command| EC["ExecutorConfig\n.cycle_estimation: bool"]
    EC --> GVA["get_valgrind_args()"]
    GVA -->|"if config.cycle_estimation"| ARG["--cycle-estimation=yes\n(added to args vec)"]
    ARG --> TOOL{SimulationTool?}
    TOOL -->|Callgrind| CG["--tool=callgrind\n(valid ✓)"]
    TOOL -->|Tracegrind| TG["--tool=tracegrind\n(may reject unknown flag ⚠)"]

Loading

_{Reviews (1): Last reviewed commit: "feat(runner): add experimental --cycle-e..." | Re-trigger Greptile}

[greptile-apps]

ArgAction::Set with a bool type requires an explicit value on the command line — the user must pass --cycle-estimation=true rather than just --cycle-estimation. The sibling flag --experimental-fair-sched uses the implicit presence style (no action, defaults to SetTrue), so this inconsistency will surprise users. Changing to clap::ArgAction::SetTrue (or simply removing the action line) matches the existing flag's UX and lets --cycle-estimation act as a bare toggle.

Suggested change

	#[arg(
	long,
	default_value_t = false,
	action = clap::ArgAction::Set,
	help_heading = "Experimental",
	env = "CODSPEED_CYCLE_ESTIMATION"
	)]
	pub cycle_estimation: bool,
	#[arg(
	long,
	default_value_t = false,
	help_heading = "Experimental",
	env = "CODSPEED_CYCLE_ESTIMATION"
	)]
	pub cycle_estimation: bool,

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

--cycle-estimation is a Callgrind-specific option, but it is injected before the match tool block, so it will also be passed when SimulationTool::Tracegrind is selected. If Tracegrind does not recognise this option, valgrind will exit with an error for any user who combines --cycle-estimation with the Tracegrind simulation tool. Moving the push inside the SimulationTool::Callgrind arm (alongside the other Callgrind-specific args) would prevent this.