Improve arch/cpu detection/selection on ARM and AArch64 #18100
Conversation
| // This is the most reliable way I can find | ||
| // `/proc/cpuinfo` changes between kernel versions | ||
| struct utsname name; | ||
| if (uname(&name) >= 0) { |
There was a problem hiding this comment.
should we suggest this to llvm too?
There was a problem hiding this comment.
Potentially by including this in the feature detection function. The LLVM cpu/feature separation seems to be inconsistent with other targets since the cpu list doesn't include any generic target (other than the "generic" target itself). This is possibly related to the difficulty to determine the base instruction set. I'll probably open an LLVM issue asking about this.
There was a problem hiding this comment.
|
Trying to build this branch on scaleway: |
yuyichao
force-pushed
the
yyc/threads/arm
branch
2 times, most recently
from
dc36640 to
6e84766
Compare
|
The regex error is a gcc bug (IIUC it's regex support isn't complete until a later version, either 4.9 or 5.0) Should be fixed now since it's not using regex anymore. |
|
What platform do we want to build the ARM binary for? According to https://build.julialang.org/builders/package_tarballarm/builds/700/steps/make/logs/stdio it's currently using the Personally I only care about armv7+ (possibly armv7-r in additional to armv7-a) but RPI0 and RPI1 B+ are both armv6. |
|
I am ok with armv7. At least that is what all of us have access to test on. If there is a lot of demand for armv6, we can always do it later. |
yuyichao
force-pushed
the
yyc/threads/arm
branch
2 times, most recently
from
c646bbb to
32f54b1
Compare
|
Fair enough. I updated the readme to mention that the ARM binary we provide is armv7-a only. Also adds auto detection of known A profile so that the arm buildbot should automatically build sysimg with A profile too. |
yuyichao
force-pushed
the
yyc/threads/arm
branch
from
32f54b1 to
5873beb
Compare
* Allow `cpu_target` to specify a generic arch, matching the behavior on x86
* Detect the CPU arch version with `uname`
* Require `armv6`
Close #13270 (`armv5` is not supported)
Fix #18042
* Remove warning about generic arch since it's not really useful
Fix #17549
* Require at least the same ARM arch version and profile the C code is compiled with
yuyichao
force-pushed
the
yyc/threads/arm
branch
from
5873beb to
5977167
Compare
|
Still crashes for me in the building of the system image like before now, but hopefully llvm 3.9 will fix that. |
| // armv8-m.base, armv8-m.main | ||
| // | ||
| // Supported AArch64 arch names on LLVM 3.8: | ||
| // armv8.1a, armv8.2a |
There was a problem hiding this comment.
it's too bad llvm felt ProcDesc needed to be private: http://llvm.org/docs/doxygen/html/MCSubtargetInfo_8h_source.html#l00033
or we could have auto-generated this list for the user on-demand and provided useful help messages.
There was a problem hiding this comment.
The list is auto-generated with llc and is just listed here for better reference. We also support generating this list with julia -C help.
There was a problem hiding this comment.
OTOH, not having access to this list at runtime (other than letting LLVM printing a help message) mean that some of the logic above has to be hard coded instead of going through a fallback list and printing the cpu/feature not-recognized warning once instead of once every codegen....
There was a problem hiding this comment.
I didn't realize that worked. In llvm 3.3, it also called exit, but now it continues, so I guess we could intentionally create a TargetMachine("help") for the user. As it is now, we print the help several times, then error (probably because it fell back to "generic" arch)
* Allow `cpu_target` to specify a generic arch, matching the behavior on x86
* Detect the CPU arch version with `uname`
* Require `armv6`
Close #13270 (`armv5` is not supported)
Fix #18042
* Remove warning about generic arch since it's not really useful
Fix #17549
* Require at least the same ARM arch version and profile the C code is compiled with
(cherry picked from commit 760bc41)
ref #18100
|
Bisecting on release-0.5, the backport of this is causing segfaults during bootstrap repeatably. Not always at the exact same place, but early on: |
|
This only affects the flags we pass to llvm so it's most likely LLVM bug. Backtrace? |
|
Turn on Dump the llvm ir of the segfaulting function with Last time I saw this issue on scaleway somehow passed the wrong argument for a expression splicing. |
|
here's master, segfaults earlier https://gist.github.com/92a510dad180b42779e1e29677652d67 |
|
llvm must have relocated jl_get_ptls_states wrong? The IR looks a bit strange there. And it looks like we shouldn't have needed to emit the ptls either, but that's a separate issue |
|
Oh wait, sorry. That's supposed to be the ssp |
|
As Jameson said, it seems that LLVM uses the wrong address for |
|
release build of master https://gist.github.com/6a6b96e0cfdf50407810eb614e742ad1 |
|
In that one, it's clearly trying to load the GOT for jl_get_ptls_states from 0x81b300. Why isn't this a PIC value? |
|
This really look like the relocation/code model issue we need to workaround on ARM by turning off fastisel. Maybe you can check what flags are we passing to LLVM? diff --git a/src/codegen.cpp b/src/codegen.cpp
index 2789963..07406e3 100644
--- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -5732,12 +5732,16 @@ static inline SmallVector<std::string,10> getTargetFeatures(std::string &cpu)
}
#endif
+ jl_safe_printf("CPU: %s\nFeatures: ", cpu.c_str());
+
SmallVector<std::string,10> attr;
for (StringMap<bool>::const_iterator it = HostFeatures.begin(); it != HostFeatures.end(); it++) {
std::string att = it->getValue() ? it->getKey().str() :
std::string("-") + it->getKey().str();
+ jl_safe_printf("%s, ", att.c_str());
attr.append(1, att);
}
+ jl_safe_printf("\n");
return attr;
} |
|
|
Hmmm, why is |
|
Also, after specifying if (att == "v7")
continue;in front of the |
|
|
|
Ah my mistake, the above backtraces were from just a normal |
|
Is the |
|
I'm going to revert this for now on release-0.5 until we figure out why it's causing problems. |
|
I set the CPU to generic, and tried disabling |
|
I successfully built on arm with 0.5-rc4 on scaleway, but can't build on master, which seems to be due to this PR - which @tkelman reverted on release-0.5. |
|
Both, |
|
On the cortex A15, using |
* Allow `cpu_target` to specify a generic arch, matching the behavior on x86
* Detect the CPU arch version with `uname`
* Require `armv6`
Close #13270 (`armv5` is not supported)
Fix #18042
* Remove warning about generic arch since it's not really useful
Fix #17549
* Require at least the same ARM arch version and profile the C code is compiled with
(cherry picked from commit d9f5334 from PR #18100)
* Allow `cpu_target` to specify a generic arch, matching the behavior on x86
* Detect the CPU arch version with `uname`
* Require `armv6`
Close #13270 (`armv5` is not supported)
Fix #18042
* Remove warning about generic arch since it's not really useful
Fix #17549
* Require at least the same ARM arch version and profile the C code is compiled with
(cherry picked from commit 760bc41 and PR #18100)
Allow
cpu_targetto specify a generic arch, matching the behavior on x86Detect the CPU arch version with
unameRequire armv6
Close Libunwind compilation error on ARM #13270 (ARMv5 is not supported)
Fix build failure on Raspberry Pi 3 #18042
Remove warning about generic arch since it's not really useful
Fix on Raspberry Pi (ARM), WARNING: unable to determine host cpu name. #17549
Require at least the same ARM arch version the C code is compiled with