jhinpan/flydsl-rocprof-cli/flyprof-report

flyprof-report — bubbles -> ranked FlyDSL changes, with proof

flyprof report is the synthesis step: it runs the knob rules engine over the bundle's bubbles/counters/tile/capture artifacts and emits REPORT.md + report.json + headlines.json. This is prep — it tells you what to change and why; applying the change and re-measuring is a separate, deliberate act.

Runbook

• [ ] Ensure the bundle has at least capture.json + an ATT dispatch (run

flyprof-capture). counters.json is optional but improves the bound call.

• [ ] flyprof report --bundle DIR -f json. Read:
• data.bound_type (memory/compute/latency) and data.headline,
• data.optimal — if true, the kernel is near the roofline; **do not invent

an optimization**, report that it's well-tuned,

• data.recommendations[] — ranked; each has evidence (the firing signal +

the source:line it maps to), knob, api, code_change, confidence.

• [ ] For the rank-1 recommendation, open the cited evidence.source line and confirm

the evidence.waits_on op is really the dependency you'd break. The full bubble→knob catalog is references/bubble-knob-table.md.

If you apply a knob (optional, deliberate)

• [ ] Apply exactly ONE recommendation's code_change to the kernel .py.
• [ ] Re-run flyprof run <kernel> --gpu 0 into a NEW bundle.
• [ ] Diff report.json: did the rank-1 bubble's stall % drop? did bound_type

move toward the roof? Compare totals.stall_pct before/after.

Fixture gate (do not cheat the measurement)

When you have a known-good profile, write a fixture (expected top bubble class, non-zero mapped_pct, dispatch present). On a later run, compare against it. Never relax the fixture to make a run pass — a "regression" that's really a measurement artifact (wrong shape, parser grabbing the wrong line, empty dispatch) must be diagnosed, not silenced. Empty/odd results are findings; investigate the capture before trusting a perf delta.