SPIRV: Truncate Int128 to Int64

[michel2323]

In Julia >=1.12, the SPIRV translator encounters Int128s when running the oneAPI.jl tests. This PR truncates Int128 to Int64 and prevents the translator from crashing. Additionally, it provides the user with clear information on the truncation.

See JuliaGPU/oneAPI.jl#529 and #101

[codecov]

Codecov Report

❌ Patch coverage is 21.81818% with 86 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.67%. Comparing base (6c7d659) to head (5885f2a).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
src/spirv.jl	21.81%	86 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #728      +/-   ##
==========================================
- Coverage   75.26%   73.67%   -1.60%     
==========================================
  Files          24       24              
  Lines        3635     3745     +110     
==========================================
+ Hits         2736     2759      +23     
- Misses        899      986      +87     

☔ View full report in Codecov by Sentry.
📢 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.

[vchuravy]

Oof that's a tough one. I feel like we should actually do the soft implementation instead of truncating to the lowbit

[michel2323]

What do you mean by soft implementation? The problem is that some operations also return Int128. You mean implement a workaround for those that don't? Or add 128bit support to the Khronos translator? I think the Intel backend won't support it either.

…

On Wed, Oct 8, 2025, 4:16 PM Valentin Churavy ***@***.***> wrote: *vchuravy* left a comment (JuliaGPU/GPUCompiler.jl#728) <#728 (comment)> Oof that's a tough one. I feel like we should actually do the soft implementation instead of truncating to the lowbit — Reply to this email directly, view it on GitHub <#728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXCFWTGZLMBU3AZFKRCTDD3WV5LFAVCNFSM6AAAAACIVCK3ISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBTGI3DKMZTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[vchuravy]

With "soft math" I mean doing the operations in software instead of using hardware operations. So do the lowering as you are here converting int128 into {i64, i64} and then instead of silently truncating it, perform a software i128 addition / multiplication.

As an example GCC https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html and LLVM https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/builtins

https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/multi3.c

(Note that this is similar to what we could/should do for platforms that don't have Float64)

[michel2323]

Phew. That's what I meant with teaching the translator Int128. That's quite a task. Let's say what about this as an interim fix? ;-)

I somehow wonder why this Int128 is even emitted. It happens only in one test. I looked around a bit, but it seems that LLVM doesn't provide any built-in mechanism for Int128 -> Int64, Int64. Don't most backends have to implement it, since most hardware has no 128bit registers? Should I ask the AMDGPU folks? Can't we blame the frontend?

Float64/128 emulation through Float32/Float64 is really a can of worms.

[maleadt]

Simply truncating seems bad indeed. Did you consider adding a quirk instead to override the Julia code that widens in the first place?

[michel2323]

No. Where do I add a quirk? I thought this was what you meant by quirk.

[maleadt]

Here: https://github.com/JuliaGPU/oneAPI.jl/blob/master/src/device/quirks.jl
Metal.jl has a couple extra that e.g. avoid Float64, https://github.com/JuliaGPU/Metal.jl/blob/18d5d9588d6fa0b387ccea065e712fdf5ccb5b57/src/device/quirks.jl#L72-L85

[vchuravy]

Can't we blame the frontend?

We are the frontend :/

[michel2323]

Thanks both of you! It was indeed an easy fix. This widemul was the issue https://github.com/JuliaLang/julia/blob/92af0d8cdf28c3e58c95469366ee64c4d06e5cd6/base/range.jl#L962

It only triggered with --check-bounds=on so I used the solution of Metal.jl: https://github.com/JuliaGPU/Metal.jl/blob/18d5d9588d6fa0b387ccea065e712fdf5ccb5b57/src/device/quirks.jl#L87-L94