m-j-w/CpuId.jl

CpuId does not precompile on Julia 1.9 master branch on Apple Silicon Mac

truedichotomy opened this issue · 10 comments

truedichotomy commented

There is not much information to go on but this has been the case for a few days now. I don't know exactly which Julia PR resulted in this error.

julia> Pkg.precompile()
Precompiling project...
  ✗ CpuId
  0 dependencies successfully precompiled in 1 seconds. 524 already precompiled.

julia> versioninfo()
Julia Version 1.9.0-DEV.410
Commit f555729050 (2022-04-19 03:04 UTC)
Platform Info:
  OS: macOS (arm64-apple-darwin21.4.0)
  CPU: 10 × Apple M1 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, apple-m1)
  Threads: 1 on 8 virtual cores
m-j-w commented

Having issues to reproduce. I don't have access Apple, and nightly is still at version 1.9.0-DEV.406, which compiles CpuId successfully on windows.
I'll retest in a few days when version 410 is available as nightly.

dnadlinger commented

Same (?) on 1.8.0-beta3:

julia> using CpuId
 │ Package CpuId not found, but a package named CpuId is available from a registry.
 │ Install package?
 │   (@v1.8) pkg> add CpuId
 └ (y/n/o) [y]:
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
  [adafc99b] + CpuId v0.3.0
  No Changes to `~/.julia/environments/v1.8/Manifest.toml`
[ Info: Precompiling CpuId [adafc99b-e345-5852-983c-f28acb93d879]
error: couldn't allocate output register for constraint '{ax}'
ERROR: Failed to precompile CpuId [adafc99b-e345-5852-983c-f28acb93d879] to /Users/dpn/.julia/compiled/v1.8/CpuId/jl_BF2qTX.

julia> versioninfo()
Julia Version 1.8.0-beta3
Commit 3e092a2521 (2022-03-29 15:42 UTC)
Platform Info:
  OS: macOS (arm64-apple-darwin21.3.0)
  CPU: 10 × Apple M1 Max
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, apple-m1)
  Threads: 10 on 8 virtual cores
Environment:
  JULIA_NUM_THREADS = 10
dnadlinger commented

Going just by the ax, is it pulling in some x86 assembly/register constraints?

m-j-w commented

Oh, indeed, it's only applicable to x86 compatible CPUs.
This is an ARM64 CPU, correct?
If so, then it should probably deactivate itself rather than trying to compile the x86 instructions.

truedichotomy commented

Yup, this is an ARM64 CPU.

dnadlinger commented

This is how it gets pulled in on my system:

    ControlSystems v0.12.11
        ForwardDiff v0.10.25 (*)
        DelayDiffEq v5.35.1
            NonlinearSolve v0.3.16
                ForwardDiff v0.10.25 (*)
                RecursiveFactorization v0.2.10
                    Polyester v0.6.8
                        ThreadingUtilities v0.5.0
                            ManualMemory v0.1.8
                        PolyesterWeave v0.1.5
                            ThreadingUtilities v0.5.0 (*)
                            IfElse v0.1.1 (*)
                            Static v0.6.0 (*)
                            BitTwiddlingConvenienceFunctions v0.1.3
                                Static v0.6.0 (*)
                            CPUSummary v0.1.20
                                IfElse v0.1.1 (*)
                                Static v0.6.0 (*)
                                CpuId v0.3.0 (*)       <---

…

Does Pkg2 support dependencies that are conditional on architecture? If yes, this should probably be fixed in CPUSummary, if no, then CpuId "deactivating itself" indeed seems like the way to go.

  • 👍1
m-j-w commented

Solution approach: LLVM target stored in Sys.MACHINE and Sys.ARCH to detect the cpu architecture, then disable.

m-j-w commented

I've created pull request #50 which should - hopefully - solve the precompilation issue.
However, I can't properly test it myself since I don't have access to an Apple ARM64.

@truedichotomy Would you care pulling that one and checking whether it now successfully precompiles ? Thank you!

  • 👍1
m-j-w commented

New release tomorrow.

domschl commented

Just to confirm: M1 is now fine, thank you!