[ARM CPU] SVE support for Sgemm kernel

[Aruna K (akote123)]

This PR ports the SGEMM kernel and associated packing kernels to the ARM SVE (Scalable Vector Extension) backend. Specifically, it introduces new wrapper implementations for SVE functions in lib/sve/sgemm_sve.cpp and integrates these wrappers within the existing kernel implementations.

Motivation and Context

This work is part of an ongoing effort to enhance ONNX Runtime's performance and architecture-awareness on ARM platforms. By leveraging ARM SVE, we aim to unlock better computational efficiency and scalability on modern ARM hardware.

This PR builds upon and extends the SVE work introduced in PR #25238

Performance Analysis:

Results are captured from sve 256,128 and SVE 512 supported machines.
This PR is a joint contribution by:

• Aruna K(Aruna K (@akote123))
• Nikhil R Sharma(Nikhil Sharma (@nikhilfujitsu))
• Abhishek Jain(abhijain1204fujitsu)

[Aruna K (akote123)]

Aruna K (@akote123) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

Contribution License Agreement

This Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”), and conveys certain license rights to Microsoft Corporation and its affiliates (“Microsoft”) for Your contributions to Microsoft open source projects. This Agreement is effective as of the latest signature date below.

1. Definitions.
   “Code” means the computer software code, whether in human-readable or machine-executable form,
   that is delivered by You to Microsoft under this Agreement.
   “Project” means any of the projects owned or managed by Microsoft and offered under a license
   approved by the Open Source Initiative (www.opensource.org).
   “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
   Project, including but not limited to communication on electronic mailing lists, source code control
   systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
   discussing and improving that Project, but excluding communication that is conspicuously marked or
   otherwise designated in writing by You as “Not a Submission.”
   “Submission” means the Code and any other copyrightable material Submitted by You, including any
   associated comments and documentation.
2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any
   Project. This Agreement covers any and all Submissions that You, now or in the future (except as
   described in Section 4 below), Submit to any Project.
3. Originality of Work. You represent that each of Your Submissions is entirely Your original work.
   Should You wish to Submit materials that are not Your original work, You may Submit them separately
   to the Project if You (a) retain all copyright and license information that was in the materials as You
   received them, (b) in the description accompanying Your Submission, include the phrase “Submission
   containing materials of a third party:” followed by the names of the third party and any licenses or other
   restrictions of which You are aware, and (c) follow any other instructions in the Project’s written
   guidelines concerning Submissions.
4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else
   for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
   Submission is made in the course of Your work for an employer or Your employer has intellectual
   property rights in Your Submission by contract or applicable law, You must secure permission from Your
   employer to make the Submission before signing this Agreement. In that case, the term “You” in this
   Agreement will refer to You and the employer collectively. If You change employers in the future and
   desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
   and secure permission from the new employer before Submitting those Submissions.
5. Licenses.

• Copyright License. You grant Microsoft, and those who receive the Submission directly or
  indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
  Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
  the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
  parties.
• Patent License. You grant Microsoft, and those who receive the Submission directly or
  indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under
  Your patent claims that are necessarily infringed by the Submission or the combination of the
  Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
  import or otherwise dispose of the Submission alone or with the Project.
• Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
  No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
  granted by implication, exhaustion, estoppel or otherwise.

6. Representations and Warranties. You represent that You are legally entitled to grant the above
   licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
   have disclosed under Section 3). You represent that You have secured permission from Your employer to
   make the Submission in cases where Your Submission is made in the course of Your work for Your
   employer or Your employer has intellectual property rights in Your Submission by contract or applicable
   law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
   have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
   You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
   REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
   EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
   PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
   NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
7. Notice to Microsoft. You agree to notify Microsoft in writing of any facts or circumstances of which
   You later become aware that would make Your representations in this Agreement inaccurate in any
   respect.
8. Information about Submissions. You agree that contributions to Projects and information about
   contributions may be maintained indefinitely and disclosed publicly, including Your name and other
   information that You submit with Your Submission.
9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and
   the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County,
   Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to
   exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all
   defenses of lack of personal jurisdiction and forum non-conveniens.
10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
    supersedes any and all prior agreements, understandings or communications, written or oral, between
    the parties relating to the subject matter hereof. This Agreement may be assigned by Microsoft.

@microsoft-github-policy-service agree company=“Fujitsu Research of India Private Ltd”

[Aruna K (akote123)]

CC: Edward Chen (@edgchen1) , Hariharan Seshadri (@hariharans29)

[Hariharan Seshadri (hariharans29)]

Please address the build failures and please run onnxruntime_mlas_test in your env with your change and report any failures if any here.

[Aruna K (akote123)]

onnxruntime_mlas_test
Hariharan Seshadri (@hariharans29) ,
Thank you. I have fixed CI failures and tested onxruntime_mlas_test in gr3, with #26203 fix all tests are passing

[Hariharan Seshadri (hariharans29)]

/azp run Linux QNN CI Pipeline, Win_TRT_Minimal_CUDA_Test_CI, Windows ARM64 QNN CI Pipeline, Windows GPU Doc Gen CI Pipeline, Windows x64 QNN CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[Hariharan Seshadri (hariharans29)]

Have you tried this on multiple Gemm problem shapes - Please submit comprehensive micro-benchmarks for all SVE platforms.

I tried taking this change on a Graviton4 and for a Conv heavy model (which uses Im2Col + SGemm for the Conv implementation), it slows down the model very much - when I build with --no_sve, the perf is fine again. So, it seems like this Gemm implementation is not performant for all Gemm shapes yet.

[Aruna K (akote123)]

Have you tried this on multiple Gemm problem shapes - Please submit comprehensive micro-benchmarks for all SVE platforms.

I tried taking this change on a Graviton4 and for a Conv heavy model (which uses Im2Col + SGemm for the Conv implementation), it slows down the model very much - when I build with --no_sve, the perf is fine again. So, it seems like this Gemm implementation is not performant for all Gemm shapes yet.

Yes. I have tried on different shapes ,and for large shapes tuning is required. This PR is added as patch to enable sve for gemm kernel and for larger shapes this gemm implementation has to be tuned and we are currently working on that.

[Hariharan Seshadri (hariharans29)]

Hi Aruna K (@akote123): Any plan to resume this work ? Or at the very least, can you please guide what remains to be done for perf tuning ?

[Aruna K (akote123)]

Hariharan Seshadri (@hariharans29) ,Thank you. We will resume this work .This PR we planned as SVE sgemm enablement work and do performance tuning as future task and contribute

[Aruna K (akote123)]

Hariharan Seshadri (@hariharans29) ,Thank you
Updated the PR with latest code changes, where for sve 128 it falls back to NEON and for SVE 256 and 512 it fllows SVE path.

Below table shows shape wise timing:

GEMM Performance Comparison (time in ms)

M	K	N	gr3 (32C) MLAS_SVE	gr3 (32C) MLAS_NEON	fx700 (48C) MLAS_SVE	fx700 (48C) MLAS_NEON
3072	3072	3072	26.499	30.603	45.63	190.72
256	3072	3072	2.196	2.68	6.86	19.77
256	2048	2048	1.047	1.177	2.384	10.599
2048	2048	256	1.015	1.145	3.87	20.5
2048	2048	2048	8.152	9.244	34.98	56.094

[Hariharan Seshadri (hariharans29)]

Thanks for this. I have a few PRs ahead of this in the review queue and I will get to this soon ! Meanwhile, I am happy to kick off CI and Copilot reviewing in the background.

Also there is another SVE based Gemm implementation coming in (from KleidiAI) - Need to study the overlap and synergize

#27643

[Hariharan Seshadri (hariharans29)]

/azp run Linux QNN CI Pipeline, Win_TRT_Minimal_CUDA_Test_CI, Windows ARM64 QNN CI Pipeline, Windows GPU Doc Gen CI Pipeline, Windows x64 QNN CI Pipeline

[azure-pipelines]

No pipelines are associated with this pull request.

[Hariharan Seshadri (hariharans29)]

Hi Aruna K (@akote123) - I would like to run this by one of our contacts to get more feedback. Could you please give me one more week ?
One thought I had was to see if we could use the Mlas Backend Kernel Selector (with default to off for sve gemm) ? I feel like we have limited perf data to turn this on by default. What are your thoughts on this ?

Hariharan Seshadri (@hariharans29), Thank you for update. Regarding "Mlas Backend Kernel Selector (with default to off for sve gemm)" - As for currently perf improvements are seen for SVE 256 and SVE 512 we can enable SVE for GEMM and we can add dispatcher that for sve 128 calls NEON instead of SVE as below: `

   if (svcntw() == 4u) {
    size_t rows = MlasSgemmKernelAdd(A, B, C, CountK, CountM, CountN, lda, ldc, alpha);
    return rows;
   }   
   else {
        SVE flow
`

Sorry - re-visiting this just now. Do we have perf data across a large bunch of representative M,N,K shapes for SVE 256 and 512 - or have you measured perf only across the 4 models listed in the PR description ? Personally, I am leaning towards including SVE SGemm support in MLAS and defaulting it to off (via the Mlas backend kernel selector) and allowing the user to opt-in to using this feature - atleast for 1 or 2 releases. We can announce the feature via release notes and get perf feedback. We can turn it on my default in a future release once we are satisifed it hasn't broken anything.

[Hariharan Seshadri (hariharans29)]

Could you please re-base with main (and integrate with the Mlas backend kernel selector) ? Once done, I will prioritize merging this - thanks

[Aruna K (akote123)]

Could you please re-base with main (and integrate with the Mlas backend kernel selector) ? Once done, I will prioritize merging this - thanks

Sure .I will update with patch to integrate with the Mlas backend kernel selector.
I have also captured shape wise timing as well . Will take it again after this patch and rebase and will share it here.
Thank you Hariharan Seshadri (@hariharans29).

[Aruna K (akote123)]

Hariharan Seshadri (@hariharans29),
Rebased and integrated with the Mlas backend kernel selector for sve sgemm.
The shapewise performance results on g3E are as follows:
(timings are in ms and tested in 64C machine)

M	K	N	MLAS_SVE	MLAS_NEON
3072	3072	3072	15.05	17.69
256	3072	3072	1.326	1.403
256	2048	2048	0.609	0.720
2048	2048	256	0.613	0.874
2048	2048	2048	4.800	6.053
256	256	256	0.061	0.063

[Hariharan Seshadri (hariharans29)]

Review: PR #26027 — [ARM CPU] SVE support for Sgemm kernel

Request changes. The feature is legitimately useful and the branch has done the right work in reintegrating with the Mlas backend kernel selector so it defaults off. However, one substantive design gap remains: the nullptr handling of BackendKernelSelectorConfig inside the SVE dispatch guard silently enables the SVE path on every non-session-options caller of the internal SGEMM primitives (convolution, Flash Attention, GQA, and any raw MlasGemm* call site that doesn't build a MLAS_BACKEND_KERNEL_SELECTOR_CONFIG), which directly contradicts the "off-by-default, opt-in via mlas.enable_sve_sgemm" contract you agreed on. Beyond that, the surface concerns are naming, style, testing, and -ffast-math numerical drift. Details below.

Blocking issue — default-off contract is broken for non-packed callers

The dispatch guard used in every SVE branch is (paraphrasing the diff on lines around 274, 325, 515, 608, 635, 690, 1086, 1096 of sgemm.cpp):

if (MLAS_CPUIDINFO::GetCPUIDInfo().HasArmSVE() &&
    (!BackendKernelSelectorConfig || BackendKernelSelectorConfig->enable_sve_sgemm)) {
    // SVE path
}

When BackendKernelSelectorConfig == nullptr:

• !BackendKernelSelectorConfig → true
• Short-circuit: the OR expression is true
• Combined with HasArmSVE(): SVE runs whenever the CPU supports it, regardless of session option.

Which callers pass nullptr? Looking at the actual call graph:

1. MlasSgemmOperation (non-packed path) — its internal calls to MlasSgemmCopyPackB, MlasSgemmTransposePackB, and MlasSgemmKernelLoop all pass nullptr (see the diff at lines 1313, 1315, 1325, 1350 in the new sgemm.cpp). Its own signature is not extended by the PR, so the config never gets threaded in.
2. Callers of MlasSgemmOperation — convolve.cpp (MlasConvSGemmRouteDirect, im2col + sgemm), flashattn.cpp, flashattn_gqa.cpp, and the non-packed branch of MlasSgemmThreaded itself all call MlasSgemmOperation without any awareness of the new config.
3. MlasSgemmKernelZero / MlasSgemmKernelAdd as reused from q4gemm.h, qnbitgemm.cpp, qnbitgemm_kernel_neon.cpp — these callers were left alone (correctly, since the wrappers there call the NEON versions), but the dispatch inside MlasSgemmKernelLoop still gets hit whenever MlasSgemmOperation invokes it, and MlasSgemmOperation is called from every path listed in bullet 2.

Net effect: enabling SVE support at build time (--use_sve) flips SVE on for Conv, Flash-Attention, GQA, and non-packed SGEMM by default — the exact scenario Hariharan asked to avoid via the backend kernel selector, and the exact scenario where Sept 2025 measured a slowdown on Graviton4. Only the MlasSgemmPackedOperation → MlasSgemmThreaded → MlasGemmBatch(PackedB) chain observes the session option correctly.

Two acceptable fixes:

• Fix A (minimal, matches design intent): invert the null semantics — treat "no config" as "not opted-in":

  if (MLAS_CPUIDINFO::GetCPUIDInfo().HasArmSVE() &&
      BackendKernelSelectorConfig != nullptr &&
      BackendKernelSelectorConfig->enable_sve_sgemm) {
      // SVE path
  }

  With this, nullptr callers stay on NEON. This is one-line-per-guard and matches the "off unless user opts in" wording in the kOrtSessionOptionsMlasEnableSveSgemm doc comment.
• Fix B (more invasive but more complete): thread BackendKernelSelectorConfig* through MlasSgemmOperation's signature and all its callers (Conv, Flash-Attention, GQA), so those paths can observe the opt-in too. This preserves flexibility to opt SVE in for Conv/Attention later. Fix A is fine short-term; the code inside MlasSgemmOperation will just never take the SVE branch — which is what the design says today anyway. If you go with A, the SVE branches inside MlasSgemmCopyPackB / MlasSgemmTransposePackB / MlasSgemmKernelLoop become dead code for the Conv/Attention path, which is intended.

Please pick one and apply it uniformly. This is the one issue that would prevent merging as-is.

Correctness observations

1. SVE_TRANSPOSE reference-argument contract. In the diff at line ~515, when the SVE guard fires, the entire NEON while (x >= 4) loop is replaced by a single call SVE_TRANSPOSE(D, b, ldb, x);. This only preserves observed behavior if SVE_TRANSPOSE internally consumes all x >= 4 iterations and leaves D, b, x in the same post-condition state that the NEON loop would have left them in (x < 4, D advanced by 16*4 per consumed 4, b advanced by 4 per consumed 4). Since sgemm_sve.cpp is a large collapsed diff, I couldn't verify this by eye. Please confirm this contract in a code comment above SVE_TRANSPOSE's declaration, and add at least one unit test that runs the transpose-pack path with CountY = 5, 7, 12, 13 shapes to catch off-by-one errors at the loop boundary. Same concern applies to MlasSveTransposePackBNx4<8> / <4> and the SCATTER_STORE path.
2. -ffast-math on sgemm_sve.cpp in Release. This enables -ffinite-math-only, -fassociative-math, -fno-signed-zeros, -freciprocal-math, etc. Reassociation of FMAs can perturb the last-bit-or-two of the accumulated dot product. Two consequences:
   • Numerical tests that compare against a NEON reference at tight tolerance will diverge. This should be validated against onnxruntime_mlas_test — you mentioned it passes after PR [MLAS] Fix SVE enabled pipeline break #26203, which is good, but please state in the PR body whether any tolerance had to be relaxed.
   • Model outputs will be non-bit-exact vs the NEON path even when the same session runs on the same input twice with SVE toggled. This is worth calling out in the doc comment for kOrtSessionOptionsMlasEnableSveSgemm so users considering the option know that flipping it changes numerical output.
     Consider dropping -ffast-math and re-benchmarking. If the perf gap widens materially, keep it but document.
3. HasArmSVE() call cost in the hot loop. MLAS_CPUIDINFO::GetCPUIDInfo() returns a static singleton and HasArmSVE() returns a bool member, so the cost is minor. Nonetheless, the dispatch guard runs inside per-panel and per-M-row loops. A single const bool use_sve = ... at the top of each function (or better, at the top of MlasSgemmThreaded) would be cleaner and constant-fold better. Non-blocking.
4. size_t RowsHandled = 0; change (line ~1071) is defensive and harmless — the pre-existing code had the variable initialized on every code path because each #if arm assigns it before use. Fine to leave in.
5. Config option applies to session, but Conv/Attention paths (via MlasSgemmOperation) bypass the session option even with Fix B never applied to them. This is the same point as the blocking issue but framed as "callers of the raw MlasGemm* C++ API that don't build a MLAS_BACKEND_KERNEL_SELECTOR_CONFIG observer never see the opt-in." Fix A quietly resolves this by making nullptr mean "stay on NEON."

Style and naming

1. All-caps identifier names for functions. SVE_TRANSPOSE, SVE_LOAD_STORE, SVE_ZERO_INITIALIZE, SCATTER_STORE, PACKED_B_BLOCK_WIDTH are used for functions and inline helpers in mlasi_sve.h, and MLAS convention (Google C++ style) reserves SCREAMING_SNAKE_CASE for macros only. Please rename to MlasSveTranspose, MlasSveLoadStore, MlasSveZeroInitialize, MlasSveScatterStore, kMlasSvePackedBBlockWidth — matching sibling MlasSveptrue, MlasSveTransposePackBNx4, etc.
2. TransposePackBNx8 in mlasi_sve.h is declared without the MlasSve prefix. Rename to MlasSveTransposePackBNx8.
3. Brace and spacing inconsistencies throughout the added sgemm.cpp blocks:

   if (...) {
     ...
   }
   else{             // should be `} else {`
     ...
   }

   and lines like MlasSveTransposePackBNx4<8>(&d[0], &b[0], ldb);} closing the if on the same line. Please run lintrunner / clang-format over sgemm.cpp before merging.
4. Redundant #if defined(MLAS_USE_SVE) && defined(MLAS_NEON_INTRINSICS). On any ARM64 build where MLAS_USE_SVE is defined, MLAS_NEON_INTRINSICS is also defined. Some new branches use both, others use just MLAS_USE_SVE. Pick one (MLAS_USE_SVE alone is sufficient) and be consistent.
5. #include "sve/mlasi_sve.h" at the top of sgemm.cpp, above #include "mlasi.h". If mlasi_sve.h transitively depends on types from mlasi.h, order matters. Move the SVE include after mlasi.h.
6. Duplicate NEON fallback bodies inside #elif MLAS_USE_SVE blocks. Since the SVE-enabled branch has its own else block that duplicates the NEON code, the outer #elif defined(MLAS_NEON_INTRINSICS) also has the same code. This will diverge over time when someone updates one but not the other. Consider factoring the NEON-4-lane inner body into a small local lambda / inline helper and calling it from both branches.
7. RowsHandled = 0; — the added initializer is fine but the empty line and stray formatting between #endif // platform check and C += ldc * RowsHandled; (extra blank lines) don't add value.
8. float* (trailing spaces) at line 1015 of the diff. Lint would catch.

Testing gaps

1. No new SGEMM correctness tests in onnxruntime_mlas_test.cc targeting the SVE dispatch. onnxruntime_mlas_test on a Graviton machine with mlas.enable_sve_sgemm=1 set on the session options is a manual step. Please add:
   • A gtest under onnxruntime/test/mlas/unittest/ that iterates over M ∈ {1,3,7,8,15,16,17,32,64,255,256}, N ∈ same, K ∈ same, both TransA/TransB × NoTrans/Trans, both ZeroMode ∈ {true, false}, and asserts that the SVE result matches the NEON reference to within a small ffast-math-aware tolerance (say 1e-4 relative). This is the same shape-sweep pattern used by the existing qgemm and sqnbit_gemm tests.
2. No CI leg actually runs the code. The pipelines you kicked off (Linux QNN, Windows ARM64 QNN, Windows x64 QNN, Win TRT Minimal, Windows GPU Doc Gen) don't have an ARM Linux/SVE runner. "1 / 1 checks OK" is misleading here — nothing in CI actually exercised the new SVE dispatch. Two options:
   • Add a QEMU-SVE build+test job (build with -march=armv8.2-a+sve and run onnxruntime_mlas_test under qemu-aarch64 -cpu max,sve256=on). This is what other MLAS SVE work (SVE FP16) validates against.
   • Or gate on an internal Graviton3/4 runner if one is available. Either way, a green ARM+SVE CI leg is worth adding before opt-in is merged, so the "opt-in for users to test" story doesn't rely on unreviewed code.
3. onnxruntime_mlas_test after PR [MLAS] Fix SVE enabled pipeline break #26203 — glad this passes, but please state in the PR body which platform (SVE 128 fallback via NEON? SVE 256? SVE 512?) and which vector-length branches were exercised. The perf table shows SVE-256 (g3E) numbers; a corresponding correctness sweep on the same hardware is what matters.

Perf data observations (non-blocking)

The 14-hour-ago perf table on g3E is a nice sanity check but is narrow:

M	N	K	SVE ms	NEON ms	Speedup
3072	3072	3072	15.05	17.69	1.18×
256	3072	3072	1.326	1.403	1.06×
256	2048	2048	0.609	0.720	1.18×
2048	2048	256	0.613	0.874	1.43×
2048	2048	2048	4.800	6.053	1.26×
256	256	256	0.061	0.063	1.03×

Meaningful but modest wins in the 1.0×–1.4× range on square/tall shapes. Consider adding:

• Non-square shapes that are common in transformers: M=1, N=2048, K=2048 (decode step), M=32, N=8192, K=8192 (MLP FFN), M=128, N=32000, K=4096 (LM head).
• SVE-512 numbers if you have access.
• Cold-cache vs warm-cache — the current table looks warm-cache.

Since the feature is opt-in, this is not a blocker, but it will inform whether it's worth turning on by default in a future release.

Config wiring

1. config.enable_sve_sgemm =config_options.GetConfigOrDefault(kOrtSessionOptionsMlasEnableSveSgemm, "0") == "1"; in mlas_backend_kernel_selector_config_utils.h — missing space after = (twice). Non-blocking, but lint will flag.
2. Doc comment for kOrtSessionOptionsMlasEnableSveSgemm currently reads:

   // Use SVE SGEMM kernels in MLAS if available.
   // Option values:
   // - "0": Disable Use of SVE SGEMM kernels. [DEFAULT]
   // - "1": Use SVE SGEMM kernels when available.
   

   Consider adding: // Note: only affects the packed-B SGEMM path. Convolution and Flash-Attention SGEMM invocations are unaffected by this option in the current implementation. (once you apply Fix A above, this note is accurate; if you apply Fix B, drop it.)
3. enable_sve_sgemm = false; in mlas.h correctly defaults to off. Good.

Summary

Substantive design fix needed on the nullptr guard semantics so the "opt-in" contract actually holds for the callers the option was designed to protect (Conv and Attention were the exact paths Hariharan cited perf-regressions on). Everything else is style, testing, and documentation polish. The feature itself is well-motivated and correctly scoped as opt-in for at least 1–2 releases before considering default-on. Approve after Fix A (or Fix B), a correctness gtest sweep in onnxruntime_mlas_test, and a green SVE-enabled CI leg (QEMU-SVE is the low-cost option).

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

[Aruna K (akote123)]

Performance Comparison: MLAS SVE vs MLAS NEON

Metric: Time in milliseconds (ms)

M	K	N	hpc7g.16xlarge MLAS_SVE	hpc7g.16xlarge MLAS_NEON	Fx700 48-Core MLAS_SVE	Fx700 48-Core MLAS_NEON
3072	3072	3072	15.05	17.69	37.452	199.85
256	3072	3072	1.326	1.403	7.081	20.551
256	2048	2048	0.609	0.72	3.056	10.6
2048	2048	256	0.613	0.874	6.218	20.32
2048	2048	2048	4.8	6.053	33.396	69.54
256	256	256	0.061	0.063	0.516	1.021
1	2048	2048	0.545	0.563	1.89	2.63
32	8192	8192	9.496	9.502	68.6	87.46
128	32000	4096	22.59	23.29	80.21	188.328

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (4)

onnxruntime/core/mlas/lib/sve/sgemm_sve.cpp:1156

• MlasSveTransposePackBNx4 only handles VL==16/8/4. For any other valid SVE vector length, this loop performs no stores, leaving the packed buffer uninitialized and producing incorrect GEMM results.

Add a safe fallback path for unsupported VL values (e.g., scalar transpose matching MlasSgemmTransposePackBNx4’s D[0]/D[16]/D[32]/D[48] layout).

    for (unsigned n = 0; n < N / 4; n++) {
        if (VL() == 16) {
            Transpose_SVE512_4x4(&D[0], &B[0], ldb);
        } else if (VL() == 8) {
            Transpose_SVE256_4x4(&D[0], &B[0], ldb);

onnxruntime/core/mlas/lib/sve/sgemm_sve.cpp:1223

• MlasSveScatterStore writes to d[15]/d[30]/d[45], but the packed-B layout used by the existing transpose pack routine stores rows at offsets 0/16/32/48 (see MlasSgemmTransposePackBNx4 in sgemm.cpp). These off-by-one (and off-by-two/three) offsets will corrupt the packed buffer layout.

Update the offsets to match the standard 16-float stride.

    MlasSveStoreFloat32(pb_first_half, &d[0], vec0);
    MlasSveStoreFloat32(pb_second_half, &d[15], vec0);
    MlasSveStoreFloat32(pb_third_half, &d[30], vec0);
    MlasSveStoreFloat32(pb_fourth_half, &d[45], vec0);

onnxruntime/core/mlas/lib/sve/sgemm_sve.cpp:1232

• MlasSveLoadStore uses svptrue_b32() and increments by VL(). If svcntw() is larger than (or does not evenly divide) MLAS_SGEMM_STRIDEN_THREAD_ALIGN (16), this will read/write past the intended 16-float block.

Use a predicate based on the remaining element count so this stays in-bounds for any SVE vector length.

    for (int i = 0; i < MLAS_SGEMM_STRIDEN_THREAD_ALIGN; i += VL()) {
        svfloat32_t vec0 = MlasSveLoadFloat32(svptrue_b32(), b + i);
        MlasSveStoreFloat32(svptrue_b32(), D + i, vec0);
    }

onnxruntime/core/mlas/lib/sve/sgemm_sve.cpp:1241

• MlasSveZeroInitialize stores with svptrue_b32() in chunks of svcntw(). For svcntw() > kMlasSvePackedBBlockWidth (16) this will write past the 16-float block; and for svcntw() values that don’t evenly divide 16 it can also overrun on the final iteration.

Use a predicate capped to kMlasSvePackedBBlockWidth so this always zeros exactly 16 floats.

    svfloat32_t zero = svdup_f32(0.0f);
    for (int i = 0; i < kMlasSvePackedBBlockWidth; i += svcntw()) {
        MlasSveStoreFloat32(svptrue_b32(), d + i, zero);
    }

[Aruna K (akote123)]

Hariharan Seshadri (hariharans29), mirounga
Just wanted to follow up on this PR. Please let me know if you have any comments or if there's anything I should update.

[mirounga]

There is a substantial amount of work required to bring this up to the current upstream state. You can take a look at how the Elementwise kernels have evolved and refactor SGEMM in the same key

[abhijain1204fujitsu]

There is a substantial amount of work required to bring this up to the current upstream state. You can take a look at how the Elementwise kernels have evolved and refactor SGEMM in the same key

Hi mirounga, thanks for checking the PR and sharing your feedback
We will do the needful and push the changes

[Nikhil Sharma (nikhilfujitsu)]

mirounga Sir please support this PR further. Thankyou.