Skip to content

Fix AMX detection to request OS XSAVE permission on Linux#9199

Open
alexreinking wants to merge 3 commits into
mainfrom
alexreinking/fix-amx-xsave
Open

Fix AMX detection to request OS XSAVE permission on Linux#9199
alexreinking wants to merge 3 commits into
mainfrom
alexreinking/fix-amx-xsave

Conversation

@alexreinking

Copy link
Copy Markdown
Member

On Linux, the AMX XTILEDATA state component (XCR0 bit 18) is allocated lazily: the kernel leaves it disabled until a thread explicitly requests it via arch_prctl(ARCH_REQ_XCOMP_PERM). Without this call, xgetbv() reports AMX as OS-disabled even on hardware that fully supports it, and code generated for AVX512_SapphireRapids can fault at runtime. Request the permission and gate the feature on the resulting XCR0 bits in both the AOT runtime feature-detection module and the compiler's own host-target detection in Target.cpp.

Fixes #9191

Breaking changes

None

Checklist

  • Commits include AI attribution where applicable (see Code of Conduct)

@alexreinking

Copy link
Copy Markdown
Member Author

@sanvila -- Can you test this patch, please?

@abadams abadams left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving because it looks right, but agree that it would be good to have it tested by the original reporter before merging.

@codecov

codecov Bot commented Jul 9, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@47e0ce8). Learn more about missing BASE report.

Files with missing lines Patch % Lines
src/LLVM_Runtime_Linker.cpp 75.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #9199   +/-   ##
=======================================
  Coverage        ?   69.66%           
=======================================
  Files           ?      255           
  Lines           ?    78567           
  Branches        ?    18787           
=======================================
  Hits            ?    54734           
  Misses          ?    18191           
  Partials        ?     5642           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@sanvila

sanvila commented Jul 10, 2026

Copy link
Copy Markdown

Hi. Sorry, the patch does not apply cleanly on top of the current Debian package, so I can't test this easily (I can only test Debian source packages, either from Debian unstable, or imported from some other place).

Maybe the Debian maintainer @LebedevRI has some idea about what we could do here.

@LebedevRI

Copy link
Copy Markdown
Contributor

Hi. Sorry, the patch does not apply cleanly on top of the current Debian package, so I can't test this easily (I can only test Debian source packages, either from Debian unstable, or imported from some other place).

Maybe the Debian maintainer @LebedevRI has some idea about what we could do here.

That's practically expected given that last release was almost a year ago.
One would need to manually backport the patch, e.g. by manually applying the actual textual diff.

@alexreinking alexreinking self-assigned this Jul 13, 2026
@alexreinking

Copy link
Copy Markdown
Member Author

I'll see how far I can get in WSL on my Sapphire Rapids workstation

alexreinking and others added 3 commits July 16, 2026 11:33
On Linux, the AMX XTILEDATA state component (XCR0 bit 18) is allocated
lazily: the kernel leaves it disabled until a thread explicitly
requests it via arch_prctl(ARCH_REQ_XCOMP_PERM). Without this call,
xgetbv() reports AMX as OS-disabled even on hardware that fully
supports it, and code generated for AVX512_SapphireRapids can fault at
runtime. Request the permission and gate the feature on the resulting
XCR0 bits in both the AOT runtime feature-detection module and the
compiler's own host-target detection in Target.cpp.

Fixes #9191

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@alexreinking alexreinking force-pushed the alexreinking/fix-amx-xsave branch from b1d9282 to aec76c1 Compare July 16, 2026 15:38
@alexreinking

Copy link
Copy Markdown
Member Author

Tested locally on my Sapphire Rapids workstation (Xeon w5-2455X) via WSL2. On main, I reproduced the SIGILL in correctness_tiled_matmul and on this branch, the test passes.

Without arch_prctl(ARCH_REQ_XCOMP_PERM), tileloadd faults even though XCR0 already reports the AMX bits as set. XCR0 reflects system-wide hardware/kernel capability, rather than current-process permission, so the arch_prctl call is necessary (harmless if already granted). After the call, tileloadd succeeds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Building halide on AWS machines with Sapphire Rapids

4 participants