Repository navigation
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #708 +/- ##
==========================================
+ Coverage 82.40% 82.43% +0.03%
==========================================
Files 52 51 -1
Lines 4415 4241 -174
==========================================
- Hits 3638 3496 -142
+ Misses 777 745 -32 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The LTS stack was switched to the Khronos translator because its IGC reportedly rejected the back-end's output, but no failing case was recorded. The translator meanwhile lacks support for intrinsics like `llvm.ssub.with.overflow`, so signed checked arithmetic fails to compile there. Test whether the LTS stack now accepts the back-end's SPIR-V.
6b173b6 to
7aa2afe
Compare
|
@michel2323 Could you ask Intel to include a SPIRV-LLVM-Translator bump in the LTS IGC update? IGC 2.11 bundles llvm_release_150 @ 2d4f2e7, which turns SPIR-V |
|
I ran into this issue too, and it seems to be the only remaining blocker to bring LTS to the LLVM translator. I've created a SYCL reproducer, and I'll confirm it on Aurora tomorrow and forward it to our bug tracker. |
Test PR to see whether the Aurora LTS stack (NEO 25.18, IGC 2.11) accepts SPIR-V from the LLVM back-end. #574 switched the LTS stack to the Khronos translator because its IGC reportedly didn't accept the back-end's output, but there's no recorded reproducer.
The translator is now the limiting factor: it doesn't support
llvm.ssub.with.overfloworllvm.smul.with.overflow, so signedchecked_sub/checked_mulin a kernel fail to compile withONEAPI_LTS=1(this is what broke the LTS job on #707). If the ALCF job passes here, the translator could be dropped altogether.The other LTS workarounds (BFloat16 off, strided reductions, queue draining) are unchanged.