Julia and BLAS integer sizes differ on ARM

[matbesancon]

julia> versioninfo()
Julia Version 1.7.0-DEV.398
Commit 5cd1e3e1f2* (2021-01-27 22:13 UTC)
Platform Info:
  OS: Linux (aarch64-unknown-linux-gnu)
  CPU: unknown
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, tsv110)


julia> using LinearAlgebra

julia> Int
Int64

julia> LinearAlgebra.BlasInt
Int32

This leads to bugs when calling BLAS functions

julia> v = rand(typemax(Int32) + 2);

julia> norm(v);
ERROR: InexactError: trunc(Int32, 2147483649)
Stacktrace:
  [1] throw_inexacterror(f::Symbol, #unused#::Type{Int32}, val::Int64)
    @ Core ./boot.jl:605
  [2] checked_trunc_sint
    @ ./boot.jl:627 [inlined]
  [3] toInt32
    @ ./boot.jl:664 [inlined]
  [4] Int32
    @ ./boot.jl:754 [inlined]
  [5] convert
    @ ./number.jl:7 [inlined]
  [6] RefValue
    @ ./refvalue.jl:8 [inlined]
  [7] convert
    @ ./refpointer.jl:104 [inlined]
  [8] cconvert
    @ ./essentials.jl:398 [inlined]
  [9] nrm2
    @ /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.7/LinearAlgebra/src/blas.jl:487 [inlined]
 [10] nrm2
    @ /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.7/LinearAlgebra/src/blas.jl:493 [inlined]
 [11] norm2(x::Vector{Float64})
    @ LinearAlgebra /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.7/LinearAlgebra/src/dense.jl:105
 [12] norm(itr::Vector{Float64}, p::Int64)
    @ LinearAlgebra /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.7/LinearAlgebra/src/generic.jl:627
 [13] norm(itr::Vector{Float64})
    @ LinearAlgebra /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.7/LinearAlgebra/src/generic.jl:625

[staticfloat]

This is because we do not use an ILP64 build of OpenBLAS on aarch64. I don't remember why, but this is purposeful: JuliaPackaging/Yggdrasil@ee0693f

@ViralBShah @Keno can either of you think of a reason why this is? Should we switch aarch64 BLAS to be ILP64 in the future?

[ViralBShah]

I don't remember why - but it is purposeful. Could be as simple as perhaps openblas not supporting it back then. In fact, a lot of Yggdrasil packages have conditionals for this as well. Good to revisit it and clean it up.

[matbesancon]

Should we try again to open a PR on Yggdrasil to build it? I can open it, but I doubt I'll of much use beyond "change random characters until CI says green"

[staticfloat]

I doubt I'll of much use beyond "change random characters until CI says green"

I think you underestimate how useful that is.

[staticfloat]

If Yggdrasil builds well, the next step is to try out a Julia build with that new configuration; you'll need to:

• Change which BB tarball gets downloaded by changing this version field

• add USE_BLAS64:=1 in this block

That should be enough for you to locally test and see if it works. To actually merge this into Julia, we'd also need to:

• Update the source tarball version we install if not using BB-built binaries.

• Synchronize the Yggdrasil source build flags with what we use in Julia itself, in particular, the set of patches applied.

• Update checksums by running make -f contrib/refresh_checksums.mk openblas.

[matbesancon]

add USE_BLAS64:=1 in this block

Why will this be necessary? If we are already on a 64-bits machine won't BLAS use 64 by default?

Edit: ok no I see this is an ARM-only block

[staticfloat]

The way the build system works, you need to set USE_BLAS64=1 explicitly on all platforms you want it to be the case on.

https://github.com/JuliaLang/julia/blob/master/deps/blas.mk#L43

[ViralBShah]

FWIW, whenever I am ready to land a blastrampoline PR, we will be able to remove all that complex BLAS stuff in Make.inc. I'll be opening it soon-ish, but it will take a long time to merge.

Irrespective, if we can have 64-bit blas on aarch64, the work discussed here still needs to get done.

[ViralBShah]

Fixed in #39455.

[ViralBShah]

I suppose this should be left open until the functionality is actually merged.

[dkarrasch]

#39455 got merged. Can we close this?

[matbesancon]

Yes definitely

…

On Fri, Mar 5, 2021, 20:31 Daniel Karrasch ***@***.***> wrote: #39455 <#39455> got merged. Can we close this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#39436 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2FDMRBFW6XX6OGBUXSMO3TCEWSNANCNFSM4WXFHBNQ> .