Closed Keno closed 2 years ago
Is the compiler enabling all the features available by default?
In another word, does it pass https://github.com/JuliaLang/julia/blob/a23a4ff08da5b6d95e9a35eee96e3260a452c02b/src/crc32c.c#L328 by default? Or do we have to do a +crc
one way or another ourselves.
Here's what's enabled by default:
#define __ARM64_ARCH_8__ 1
#define __ARM_64BIT_STATE 1
#define __ARM_ACLE 200
#define __ARM_ALIGN_MAX_STACK_PWR 4
#define __ARM_ARCH 8
#define __ARM_ARCH_ISA_A64 1
#define __ARM_ARCH_PROFILE 'A'
#define __ARM_FEATURE_CLZ 1
#define __ARM_FEATURE_CRYPTO 1
#define __ARM_FEATURE_DIRECTED_ROUNDING 1
#define __ARM_FEATURE_DIV 1
#define __ARM_FEATURE_FMA 1
#define __ARM_FEATURE_IDIV 1
#define __ARM_FEATURE_LDREX 0xF
#define __ARM_FEATURE_NUMERIC_MAXMIN 1
#define __ARM_FEATURE_UNALIGNED 1
#define __ARM_FP 0xE
#define __ARM_FP16_ARGS 1
#define __ARM_FP16_FORMAT_IEEE 1
#define __ARM_NEON 1
#define __ARM_NEON_FP 0xE
#define __ARM_NEON__ 1
#define __ARM_PCS_AAPCS64 1
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_SIZEOF_WCHAR_T 4
Since I doubt there'll be a mac without crc32, we should just add that to the default feature flags in our Makefile. For everything else we can do runtime detection with sysctl.
I'm surprised that it enables crypto but not crc.... Yeah, I don't think it's worth doing a runtime detection here.
And from https://github.com/JuliaLang/julia/pull/36592#issuecomment-656984903 it doesn't seem to provide all the features that LLVM may use
The features detectable currently appears to be
hw.optional.neon_fp16
: fullfp16
hw.optional.armv8_1_atomics
: lse
hw.optional.armv8_crc32
: crc
hw.optional.armv8_2_fhm
: fp16fml
__ARM_FEATURE_CRYPTO
(compile time): aes
, sha2
The ones that should be supported on that CPU (all requirement from armv8.3-a) are jsconv
, complxnum
, rcpc
, ccpp
, rdm
. Some of the floating point ones are quite intereting.
Also intereting that since fp16fml
is reported the featureset is closer to that of a13 than a12. (that or the LLVM feature set for a12 is wrong...)
Anyway, this is probably a low priority item...
Looks like they're just shipping an old LLVM, e.g. if I try to build jsconv (just to see whether it would run) fatal error: error in backend: Cannot select: intrinsic %llvm.aarch64.fjcvtzs
Huh, which LLVM version do they have? Over at https://github.com/JuliaLang/julia/blob/a23a4ff08da5b6d95e9a35eee96e3260a452c02b/src/features_aarch64.h#L24 I was assuming as long as the feature is available in AArch64.td it's usable... Is that not the case? (and/or is that a mac only problem?)
Huh, which LLVM version do they have
I don't know. It claims to be LLVM 12, but Apple lies about versions. I'm building upstream clang now to try it out.
It also seems that although the feature was added in https://reviews.llvm.org/D54633 which is in LLVM 8.0 the intrinsic wasn't added until https://reviews.llvm.org/D64495 much later. Does that error mean that it's a recognized intrinsic but just isn't supported by the backend? I guess just writing inline assembly shoud be good enough for testing.
Fails upstream too.
Works with raw llc and +mattr though, so I'm gonna say it does exist.
... I thought the error you got is a backend one..... (so llc should behave the same as clang = = ....., unless clang emits the wrong IR...)
I manually added the correct mattr
to llc. I also managed to get it to work with -mcpu=apple-a12
at the clang level (appears to default to apple-a7). I filed an issue with Apple to get a better error message as well as bumping the default.
Ah, OK. So you didn't set the target when running with clang.
I tried, but mattr=armv8.3-a+jsconv
didn't seem to do it.
From worker 14: While deleting: i8* %splitgep From worker 14: An asserting value handle still pointed to this value! From worker 14: UNREACHABLE executed at /Users/julia/julia/deps/srccache/llvm-10.0.0/lib/IR/Value.cpp:917!
Ah, this is where I've seen this issue... It's not Darwin or ARM/AArch64 specific and it's fixed by https://reviews.llvm.org/D84031
Can we get a BB shard going without the Fortran compiler, and see how much of the BB ecosystem can be built?
Just thinking out aloud here. The major use of Fortran in the julia build is to build LAPACK (part of the openblas build). We could have a Fortran to Julia translator and move LAPACK to Julia. Of course BB has a bunch of other fortran libraries, and there's lot of commercial software packages that need fortran compilers.
We could have a Fortran to Julia translator and move LAPACK to Julia.
If anyone is interested in helping, I'll be happy to add and maintain Fortran to Julia translator in LFortran. We already have LLVM and C++ backends. It took us quite some time to get to this point, as a lot of infrastructure had to be figured out and implemented, but we now have a foundation of a production C++ implementation of the compiler and are making rapid progress in adding features. As an example of what works already, this Fortran code:
gets correctly translated to this C++ code (and it compiles and runs):
https://gitlab.com/lfortran/lfortran/-/blob/master/tests/reference/cpp-arrays_04-ae9bd17.stdout
The C++ translator itself is implemented here: https://gitlab.com/lfortran/lfortran/-/blob/7384b0ff81eaa2043281e48ae5158d34fcbf26f6/src/lfortran/codegen/asr_to_cpp.cpp, as you can see it is a simple visitor pattern over the Abstract Semantic Representation (ASR) which contains all the types and everything is figured out and ready for LLVM or C++ translation.
I don't like making predictions how long it will take us to be able to compile Lapack, but I am hoping it is in the range of months now.
Assuming we could translate Lapack to C++ (or Julia also) automatically and correctly and quickly in a few months, what would be the workflow?
I can imagine two workflows in the future:
You translate once and just maintain the resulting code in C++ (or Julia). We will try to ensure the translator produces a nice readable and maintainable C++ code.
You keep Lapack in Fortran, but translate each new version to C++ or Julia. That way when upstream makes some changes, you will get them.
Regarding speed and performance of the translated code, that is currently unclear to me whether there can be some obstacle that would prevent it to match the performance of the original Fortran code. But we will find out, and I would think it should be possible to translate in a way to keep the performance.
LAPACK will keep moving upstream. So we have to keep running the translator on any new version - perhaps could even be integrated into BinaryBuilder. Performance shouldn't be a major problem - since 90% of the performance is anyways from calling the BLAS. The main problem will be testing correctness. Presumably the LAPACK tests translated + Julia tests may be sufficient to get started.
@ViralBShah that makes sense. Regarding correctness: my goal is for people to use LFortran as a regular Fortran compiler via LLVM, which will ensure that the parsing -> AST -> ASR -> LLVM is all correct. The ASR -> C++ backend is thus starting from a well tested starting point (ASR) that has been exercised well via the LLVM route, so there will be bugs, but they will be well isolated, and engineering-wise I think this can be delivered and made robust. The ASR -> Julia backend would be similar.
I am very excited about this, and I will keep you updated. As I said, it will take us probably months to get something initially usable, and then it takes time to mature everything, so I don't want to give you false hope that it can fix your immediate problem; but I will work towards this, I think it will become very useful to a lot of people once it matures.
I think for actively developed upstream projects, we'd rather just use lfortran as a straight LLVM compiler. The automatic translation part mostly makes sense where people want to do new development in Julia.
Just learned that there’s some ongoing effort at porting the GCC backend: https://github.com/iains/gcc-darwin-arm64
Yep, we're on top of it (https://github.com/JuliaPackaging/Yggdrasil/pull/1626), thanks!
Should LLVM9 process ARM64 relocations incorrectly
be marked done, since the linked PR is merged?
I've updated the tracking list with all items I currently know about.
I wonder how well Julia will run on Rossetta 2.
Works ok, but at reduced perf of course.
Probably reduced performance, but the M1, 16GB is quite fast when compared to my 2015 13" MBP with an i5, even while on Rosetta.
I'm curious about Julia benchmarks even with Rosetta, and I might do them at some point in the coming weeks, but don't have a more recent computer to compare to.
I'll be curious to see if the tests all pass.
That's a great question! Running the tests now.
Ok, the results are available here:
https://gist.github.com/angeris/f1263dde142f85b0270de71428cfbef8
Essentially, only one test failed, and here is the output of that:
(libuv) kqueue(): Too many open files
stress (1) | 24.44 | 0.04 | 0.2 | 93.66 | 1419.20
Worker 2 failed running test misc:
Some tests did not pass: 1280997 passed, 1 failed, 0 errored, 0 broken.
misc: Test Failed at /Applications/Julia-1.5.app/Contents/Resources/julia/share/julia/test/misc.jl:474
Expression: Libc.errno() == 0x00c0ffee
Evaluated: 0 == 0x00c0ffee
Stacktrace:
[1] record(::Test.DefaultTestSet, ::Union{Test.Error, Test.Fail}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:775
[2] (::var"#23#32")() at /Applications/Julia-1.5.app/Contents/Resources/julia/share/julia/test/runtests.jl:342
[3] cd(::var"#23#32", ::String) at ./file.jl:104
[4] top-level scope at /Applications/Julia-1.5.app/Contents/Resources/julia/share/julia/test/runtests.jl:75
[5] include(::Function, ::Module, ::String) at ./Base.jl:380
[6] include(::Module, ::String) at ./Base.jl:368
[7] exec_options(::Base.JLOptions) at ./client.jl:296
[8] _start() at ./client.jl:506
I'm not quite sure what is causing this "too many open files" (which appears to be a separate issue) but it may also be worth checking?
EDIT: The complete output is available here. As a side note, the timing results are probably not super useful since I have a few other things open and running.
Did anyone manage to build Julia on macOS 11 arm64? I tried the master branch, which fails due to LLVM problems and then I tried release 1.5.3 which fails, too:
/usr/local/src/julia % make OPENBLAS_USE_THREAD=0
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C scratch/openblas-33f76a6c378681ac2af76b20e55ff682191a1937/ CC=clang -stdlib=libc++ -mmacosx-version-min=10.8 FC=gfortran -mmacosx-version-min=10.8 LD=ld RANLIB=ranlib TARGET=ARMV7 BINARY= USE_THREAD=0 NO_AFFINITY=1 CFLAGS= -O2 FFLAGS= -O2 -fPIC LDFLAGS= -Wl,-rpath,'@loader_path/' MAKE_NB_JOBS=0
ar: creating archive ../libopenblas_armv7-r0.3.9.a
memory.c:1987:62: warning: format specifies type 'unsigned long' but the argument has type 'void *'
[-Wformat]
printf("error code=%d,\trelease->address=%lx\n",errsv,release->address);
~~~ ^~~~~~~~~~~~~~~~
1 warning generated.
make[3]: *** No rule to make target `../kernel/arm64/amin.S', needed by `samin_k.o'. Stop.
make[2]: *** [libs] Error 1
*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were errors building SandyBridge support. Both these options can also be used simultaneously. ***
make[1]: *** [scratch/openblas-33f76a6c378681ac2af76b20e55ff682191a1937/build-compiled] Error 1
make: *** [julia-deps] Error 2
@jheinen it seems like julia is not ready yet. For x86 it's enough to just install gcc via homebrew and gcc10 can now be installed on arm.
I get some strange errors which I'm not sure how to fix on CC src/runtime_ccall.o
step.
So you get the same result that I got. I installed GCC 11 from scratch. I could built all GR dependencies from source, even Qt 5.15.2. So, I thought it would only be a small step to get Julia up and running.
With two patches I managed to build Julia, but I can't run it:
JULIA usr/lib/julia/corecompiler.ji
ERROR: Unable to load dependent library /opt/src/julia/usr/lib/libgcc_s.2.dylib
Message:dlopen(/opt/src/julia/usr/lib/libgcc_s.2.dylib, 10): no suitable image found. Did find:
/opt/src/julia/usr/lib/libgcc_s.2.dylib: code signature in (/opt/src/julia/usr/lib/libgcc_s.2.dylib) not valid for use in process using Library Validation: Trying to load an unsigned library
make[1]: *** [/opt/src/julia/usr/lib/julia/corecompiler.ji] Error 1
make: *** [julia-sysimg-ji] Error 2
Any ideas?
hi, i install the julia in m1 using Rosetta, there is a issue when using add:
pkg> add FFTW
Updating registry at ~/.julia/registries/General
######################################################################## 100.0%
tar: truncated gzip input
tar: Error exit delayed from previous errors.
┌ Warning: could not download https://pkg.julialang.org/registry/23338594-aafe-5451-b93e-139f81909106/5b130d8c1b9f23da50fad7280efdd76529fa0228
└ @ Pkg.Types /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Types.jl:1123
ERROR: SystemError: opening file "/var/folders/y2/d_wnz2hs61z4twjv56ww0bc80000gn/T/jl_0XxCJq/Registry.toml": No such file or directory
Stacktrace:
[1] systemerror(::String, ::Int32; extrainfo::Nothing) at ./error.jl:168
......
[28] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:1144
[29] (::REPL.var"#38#42"{REPL.LineEditREPL,REPL.REPLBackendRef})() at ./task.jl:356
Has anyone solved this problem? Thanks!
@jiaqiwang969 I also encounter this issue. I think it is an issue from the PkgServer, but not Julia itself.
Currently, I solve this issue by changing the mirror of the PkgServer by setting
julia> ENV["JULIA_PKG_SERVER"] = "https://mirrors.bfsu.edu.cn/julia"
Then everything goes well for me.
How can I find out what the problem is. The macOS build on arm64 (Apple M1) always hangs here:
JULIA usr/lib/julia/corecompiler.ji
JULIA usr/lib/julia/sys.ji
coreio.jl
exports.jl
essentials.jl
ctypes.jl
gcutils.jl
generator.jl
reflection.jl
options.jl
promotion.jl
tuple.jl
expr.jl
pair.jl
traits.jl
range.jl
error.jl
bool.jl
number.jl
int.jl
operators.jl
pointer.jl
refvalue.jl
refpointer.jl
checked.jl
indices.jl
array.jl
abstractarray.jl
subarray.jl
views.jl
baseext.jl
ntuple.jl
abstractdict.jl
iddict.jl
idset.jl
iterators.jl
namedtuple.jl
./build_h.jl
./version_git.jl
hashing.jl
rounding.jl
div.jl
float.jl
twiceprecision.jl
complex.jl
rational.jl
multinverses.jl
abstractarraymath.jl
arraymath.jl
simdloop.jl
reduce.jl
reshapedarray.jl
reinterpretarray.jl
bitarray.jl
bitset.jl
multimedia.jl
some.jl
dict.jl
abstractset.jl
set.jl
char.jl
strings/basic.jl
strings/string.jl
strings/substring.jl
osutils.jl
c.jl
io.jl
iobuffer.jl
intfuncs.jl
strings/strings.jl
strings/search.jl
strings/unicode.jl
strings/util.jl
strings/io.jl
regex.jl
pcre.jl
./pcre_h.jl
parse.jl
shell.jl
BTW: I code-signed the BB libraries using my Apple developer account. Does someone know how to obtain (and use) the original certificate?
I think @vtjnash or @Keno may be better people to suggest what to do. But I would just start the compilation in gdb and then hit ctrl-c where it is stuck to try see what's going on. And maybe even build a smaller minimal system image to start with.
That hang is one of the known issues, but I forget which one - probably either the PCRE or the libunwind one.
Looks like PCRE2 10.36 is out. I'll try to get that integrated
The upstream bug reported related to PCRE2 is still open though, and the release announcement suggests that it's still a problem
You'll need to carry the patch for it. I think @staticfloat may have even already picked it up.
I have not. PCRE2 10.36 still doesn't contain the fix; see here for discussion: https://bugs.exim.org/show_bug.cgi?id=2618#c23
Ok, somebody just needs to pick up that upstream fix then. I had built a version of 10.36rc1 with the patch applied and it built cleanly and worked, so I'm imagining it should be easy to do for the final 10.36 release.
Thanks for the hint. I checked out 1a8f196985, but the problem still exists:
JULIA_BINDIR=/opt/src/julia/usr/bin /opt/src/julia/usr/bin/julia -g1 -O0 -C "apple-a12" --output-ji /opt/src/julia/usr/lib/julia/sys.ji.tmp --startup-file=no --warn-overwrite=yes --sysimage /opt/src/julia/usr/lib/julia/corecompiler.ji sysimg.jl ./
Julia seems to enter an endless loop when processing shell.jl
and consumes 100% CPU.
I'm probably doing something wrong. The build still uses PCRE2.v10.35.0+0.aarch64-apple-darwin.tar.gz
.
Try:
make -C deps uninstall
and remove the usr
dir in the julia build directory.
I removed everything (also the srccache
directory) but the build still downloads (and uses) deps/srccache/PCRE2.v10.35.0+0.aarch64-apple-darwin.tar.gz
.
I'm on 1a8f196985 (HEAD -> cv/pcre2-10.36, origin/cv/pcre2-10.36) Update PCRE2 to 10.36
The PR does not include a BB bump yet. You can build it from source or wait for that to be included.
ah - ok. I'll wait for the BB version then ...
I figured it would be worth having a single issue to track all the known issues on Apple Silicon. I'll try to keep this list updated as things get fixed or people encounter additional issues.
MacOS(:aarch64)
as a valid platform (https://github.com/JuliaLang/Pkg.jl/pull/1916)Hook up ARM feature detection (viasysctl hw.optional
)worlds
test:numbers
test (related to SIGFPE handling) (#39894):complex
test: complex (2) | started at 2020-11-13T00:39:12.332complex
test (filed as #38419)make debug
(#39823)