[Maintain][Manifest] add at least 2 workloads to 21 binary elementwise ops#1392
Conversation
…e ops AddFwdOp/SubFwdOp and 19 sibling binary ops in elementwise_binary.yaml had empty workloads while status was implemented, causing test_every_op_has_at_least_two_workloads to fail in gpu-smoke. Each affected op now declares two representative workloads: - LLM hidden-state prefill: input/other 2048x4096 (no broadcast) - CNN feature map with channel-wise broadcast: input 16x256x56x56, other 256x1x1 Dtype matrix matches each op's signature: float ops use float16/bfloat16, bitwise ops use int32/int64, logical ops use bool. No signature, roofline, params, shape_rules, or dtype_combos changes. Manifest-only PR per the trust-model carve-out. Co-Authored-By: Ibuki 🍃 — a wind born from GPTs <Ibuki-wind@users.noreply.github.com>
There was a problem hiding this comment.
Code Review
This pull request populates the workloads section for numerous element-wise binary operations in the manifest. The review feedback identifies critical mismatches in workload keys for PowFwdOp and LerpFwdOp, where the keys should align with the specific input names exponent and end rather than other_shape. Furthermore, the reviewer suggests expanding the dtypes lists for several operations to include all types supported by their signatures, such as float32 for arithmetic ops and additional types for logical and bitwise operations, to improve test and benchmark coverage.
There was a problem hiding this comment.
Pull request overview
This PR addresses a gpu-smoke manifest schema failure (test_every_op_has_at_least_two_workloads) by populating previously-empty workloads: lists for a set of implemented binary elementwise ops in the manifest, enabling downstream tooling/benchmarks to consume representative shapes/dtypes.
Changes:
- Added two representative workload entries (LLM hidden-state + CNN broadcast) to 21 binary elementwise ops in
tileops/manifest/elementwise_binary.yaml. - Standardized dtype selections per op category (float, logical, bitwise) within the new workload entries.
- PowFwdOp workloads use exponent_shape (matches signature input name) - LerpFwdOp workloads use end_shape (matches signature input name) - Add float32 to dtype lists where supported by signature - Expand LogicalAnd/Or workload dtypes to include float types - Expand BitwiseAnd/Or/Xor workload dtypes to include bool Co-Authored-By: Ibuki 🍃 — a wind born from GPTs <Ibuki-wind@users.noreply.github.com>
Ibuki-wind
left a comment
There was a problem hiding this comment.
Overall
The manifest update still needs a signature-aligned cleanup pass before it satisfies the workload contract.
… (cherry-pick #1392) (#1395) ## Summary Cherry-pick of #1392 (already merged to `testbed` as `67e10ad`) onto `main`. `main` CI is currently red because it lacks this manifest fix. Landing the same patch on `main` directly unblocks CI without waiting for the next `testbed` → `main` rollup. ## Why this is conflict-safe for the eventual testbed → main merge The cherry-pick is byte-identical to `67e10ad`. When `testbed` later merges into `main`, the 3-way merge sees the same change on both sides and resolves automatically — no duplicate diff, no conflict (assuming no further `testbed` commits touch the same lines). ## Test plan - [ ] CI green on this PR - [ ] After merge, confirm `main` unit tests pass Co-authored-by: Ibuki 🍃 — a wind born from GPTs <Ibuki-wind@users.noreply.github.com>
Summary
Fix gpu-smoke
test_every_op_has_at_least_two_workloadsfailure by populating emptyworkloads:lists on 21 implemented binary elementwise ops (`AddFwdOp`, `SubFwdOp`, `MulFwdOp`, `DivFwdOp`, `RemainderFwdOp`, `PowFwdOp`, `FloorDivideFwdOp`, `LerpFwdOp`, `MaximumFwdOp`, `MinimumFwdOp`, `Eq/Ne/Gt/Lt/Ge/LeFwdOp`, `LogicalAnd/OrFwdOp`, `BitwiseAnd/Or/XorFwdOp`).This pre-existing testbed CI break has been blocking nightshift auto-merge for PRs #1387, #1388, #1389, #1391. Filed as issue #1390 — this PR resolves it.
Plan executed
Each affected op now declares two representative workloads:
Dtype matrix matches each op's signature:
Test plan
Acceptance Criteria
Closes #1390.
Trust model
Manifest-only PR. No `signature`, `roofline`, `params`, `shape_rules`, or `dtype_combos` edits. Falls within the trust-model rule that workload edits without a status flip require a separate manifest-only PR with human review — this is that PR.