[MLAS] Do not build the POWER MLAS kernels when VSX is unavailable - #32389
Merged
Hariharan Seshadri (hariharans29) merged 1 commit intoSep 3, 2026
Merged
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused change correctly selects generic MLAS kernels on PowerPC targets without VSX.
Pull request overview
Aligns MLAS source selection with MLAS_TARGET_POWER by falling back to generic kernels when VSX is unavailable.
Changes:
- Adds a compile-time VSX capability probe.
- Disables POWER-specific sources when the probe fails.
No actionable issues identified.
File summaries
| File | Description |
|---|---|
cmake/onnxruntime_mlas.cmake |
Guards POWER kernel selection with a VSX compiler check. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Hariharan Seshadri (hariharans29)
changed the title
Copilot started reviewing on behalf of
Hariharan Seshadri (hariharans29)
September 2, 2026 17:47
View session
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Clearing the shared POWER architecture flag breaks Java packaging on no-VSX PowerPC builds.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Balanced
mlas.h only defines MLAS_TARGET_POWER when __VSX__ is defined, so on PowerPC targets whose default baseline lacks VSX (for example FreeBSD/powerpc64, whose big-endian baseline is a 970-class CPU with AltiVec but no VSX) MLAS itself falls back to the generic implementation. onnxruntime_mlas.cmake, however, still adds the power/ kernel sources and dgemm.cpp for every powerpc* processor. Those translation units cannot compile without VSX: mlasi.h only includes <altivec.h> under __VSX__, so vec_splat and friends are undeclared, and the MLAS_FLOAT64X2 type and the double-precision helpers exist only for MLAS_VSX_INTRINSICS: onnxruntime/core/mlas/lib/power/FgemmKernelpower.h:155:27: error: use of undeclared identifier "vec_splat" onnxruntime/core/mlas/lib/power/DgemmKernelPower.cpp: error: unknown type name "MLAS_FLOAT64X2" Probe for __VSX__ and skip the POWER-specific sources when it is absent, so that such targets build with the generic kernels, matching what mlas.h already decides at the preprocessor level. The probe result is carried in a separate MLAS_HAS_VSX variable rather than clearing POWER, because onnxruntime_java.cmake uses POWER to select the Java packaging architecture. Tested on FreeBSD 15.1/powerpc64 (big-endian): the build proceeds past MLAS with the generic kernels; powerpc64le (VSX baseline) is unaffected.
Piotr Kubaj (pkubaj)
force-pushed
the
ppc64-fix
branch
from
September 2, 2026 19:16
dfa876c to
2c1afd3
Compare
Hariharan Seshadri (hariharans29)
approved these changes
Sep 3, 2026
Hariharan Seshadri (hariharans29)
enabled auto-merge (squash)
September 3, 2026 20:30
Hariharan Seshadri (hariharans29)
merged commit Sep 3, 2026
a535bcf
into
microsoft:main
90 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
mlas.h only defines MLAS_TARGET_POWER when VSX is defined, so on
PowerPC targets whose default baseline lacks VSX (for example
FreeBSD/powerpc64, whose big-endian baseline is a 970-class CPU with
AltiVec but no VSX) MLAS itself falls back to the generic
implementation. onnxruntime_mlas.cmake, however, still adds the power/
kernel sources and dgemm.cpp for every powerpc* processor. Those
translation units cannot compile without VSX: mlasi.h only includes
<altivec.h> under VSX, so vec_splat and friends are undeclared, and
the MLAS_FLOAT64X2 type and the double-precision helpers exist only for
MLAS_VSX_INTRINSICS:
onnxruntime/core/mlas/lib/power/FgemmKernelpower.h:155:27: error: use of undeclared identifier "vec_splat"
onnxruntime/core/mlas/lib/power/DgemmKernelPower.cpp: error: unknown type name "MLAS_FLOAT64X2"
Motivation and Context
Probe for VSX and skip the POWER-specific sources when it is absent,
so that such targets build with the generic kernels, matching what
mlas.h already decides at the preprocessor level.
Tested on FreeBSD 15.1/powerpc64 (big-endian): the build proceeds past
MLAS with the generic kernels; powerpc64le (VSX baseline) is unaffected.