Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDarwin/ARM64 tracking issue #36617
Darwin/ARM64 tracking issue #36617
Comments
Is the compiler enabling all the features available by default? In another word, does it pass Line 328 in a23a4ff +crc one way or another ourselves.
|
Here's what's enabled by default:
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 #36592 (comment) it doesn't seem to provide all the features that LLVM may use The features detectable currently appears to be
The ones that should be supported on that CPU (all requirement from armv8.3-a) are Also intereting that since 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) |
Huh, which LLVM version do they have? Over at Line 24 in a23a4ff |
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 |
Ah, OK. So you didn't set the target when running with clang. |
I tried, but |
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. |
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:
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 (JuliaPackaging/Yggdrasil#1626), thanks! |
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 (JuliaLang/Pkg.jl#1916)Hook up ARM feature detection (viasysctl hw.optional
)