Perf: align A5 TMR hot function entries

[yanghaoran29]

Summary

• add an internal 64-byte function-entry alignment attribute for Linux AArch64 builds
• align the A5 tensormap-and-ringbuffer submit, scheduler dispatch, and completion hot entries
• leave non-Linux and non-AArch64 targets unchanged

This applies the mitigation discussed in #2071. Without an explicit compile-time alignment requirement, unrelated code changes can move hot function entries and make performance-debugging results unpredictable. This change stabilizes the selected entry boundaries; it does not claim that alignment always improves performance.

Binary verification

The locally built A5 onboard AICPU shared object is AArch64 and places all three selected entries on 64-byte boundaries:

• submit_task_common: 0x1c6c0
• SchedulerContext::complete_slot_task: 0x25180
• SchedulerContext::resolve_and_dispatch: 0x2edc0

Artifact SHA-256: 9a80175755e086400bc96ab480209965ad41ba77b4db3be7e706d3d978151d8a

Testing

• editable package/runtime build: passed
• targeted pre-commit hooks for all changed files: passed
• C++ unit tests: 126/126 passed
• Python no-hardware unit tests: 2078 passed; 2 existing workflow compiler-symlink contract tests failed locally without touching the tested workflow files

No performance benchmarks were run, and this PR makes no performance-benefit claim.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b1e85c83-6438-45d7-a242-86baedb7e623

📥 Commits

Reviewing files that changed from the base of the PR and between f92b657 and b902bec.

📒 Files selected for processing (4)

• src/a5/runtime/tensormap_and_ringbuffer/runtime/hot_entry_alignment.h
• src/a5/runtime/tensormap_and_ringbuffer/runtime/orchestrator.cpp
• src/a5/runtime/tensormap_and_ringbuffer/runtime/scheduler/scheduler_completion.cpp
• src/a5/runtime/tensormap_and_ringbuffer/runtime/scheduler/scheduler_dispatch.cpp

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The change adds a platform-conditional 64-byte alignment macro and applies it to task submission, completion, and dispatch entry points.

Changes

Hot-entry alignment

Layer / File(s)	Summary
Alignment macro contract src/a5/runtime/tensormap_and_ringbuffer/runtime/hot_entry_alignment.h	Defines SIMPLER_A5_TMR_HOT_ENTRY_ALIGN as 64-byte alignment on AArch64 Linux with GCC or Clang, and as empty elsewhere.
Runtime entry-point annotations src/a5/runtime/tensormap_and_ringbuffer/runtime/orchestrator.cpp, src/a5/runtime/tensormap_and_ringbuffer/runtime/scheduler/scheduler_completion.cpp, src/a5/runtime/tensormap_and_ringbuffer/runtime/scheduler/scheduler_dispatch.cpp	Applies the macro to submit_task_common, complete_slot_task, and resolve_and_dispatch. No control-flow logic changes are introduced.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to b902b

This change stabilizes alignment for three internal AArch64/Linux hot-function entries without altering other targets or claiming a performance benefit; no actionable merge-blocking risk remains after normal checks and review.

Poem

I’m a rabbit with aligned little feet
Hot paths now sit on boundaries neat
Submit, complete, dispatch in line
Sixty-four bytes make the layout fine
No logic hops, no branches stray
Just tidy entries for the day

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: aligning A5 TMR hot function entries for performance-related reasons.
Description check	✅ Passed	The description accurately covers the platform-gated alignment change, affected functions, verification results, testing, and scope.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 4 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ChaoZheng109]

Thanks for the careful scoping and for verifying the result in the binary — the three symbol addresses check out (all divisible by 64).

Three questions before I can tell whether this change is necessary and effective.

1. Why does 64-byte alignment fix the variance?

#2071 establishes that unrelated changes move hot function entry addresses, but not why a moved address produces a 5–8% delta — there is no I-cache / branch-predictor / PMU evidence, and the issue itself labels the layout sensitivity a hypothesis. Without a mechanism it is hard to judge whether 64 is the right constraint (#2071's own follow-up notes 16 and 32 were never compared) or whether these three entries are the right ones (also an unchecked follow-up: "Align each of the three functions independently to identify which entries matter").

2. Why is the same alignment not applied to a2a3?

All three functions exist under src/a2a3/runtime/tensormap_and_ringbuffer/ under the same names (orchestrator.cpp:884, scheduler_dispatch.cpp:892, scheduler_completion.cpp:86), the two arches' target_compile_options(aicpu_kernel ...) are identical, and the TMR runtime sources differ by about 1.6% in size. Has the paired commit/parent comparison been run on a2a3?

If it has not, the a5-only scope rests on "no data elsewhere" rather than "a2a3 is unaffected" — but the name SIMPLER_A5_TMR_HOT_ENTRY_ALIGN reads as the latter to anyone picking this up later.

3. What is the measured result?

The PR verifies the binary layout and functional regression, but carries no performance data. Two numbers would settle it:

• cross-commit variance with this change landed, in the form it lands (#2071's data is aligned Commit vs aligned Parent, i.e. applied to both sides, which is not what merging this does);
• full a5 benchmark suite, main vs main + this PR. #2071 records that aligning these same three entries on main cost 7.63% on BGEMM's full AICore window. Since that is exactly what this PR does, it would be good to address that number directly rather than leave it at "no performance benchmarks were run".

CI will not catch a regression here: _st-npu-a5.yml runs the correctness pytest with no --rounds, and the repo has no performance gate — so a 7.63% slowdown passes green.

This is also #2071's own acceptance criterion: "Use reduced cross-commit variance with no new regressions as the acceptance criterion."