Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need to install compiler-rt #14818

Closed
vtjnash opened this issue Jan 27, 2016 · 11 comments
Closed

need to install compiler-rt #14818

vtjnash opened this issue Jan 27, 2016 · 11 comments
Labels
upstream The issue is with an upstream dependency, e.g. LLVM

Comments

@vtjnash
Copy link
Member

vtjnash commented Jan 27, 2016

~/julia$ ./build-llvm37/julia --precompiled=no -C generic
WARNING: unable to determine host cpu name.
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-dev+2360 (2016-01-26 23:12 UTC)
 _/ |\__'_|_|_|\__'_|  |  jb/functions/6b04549* (fork: 46 commits, 0 days)
|__/                   |  x86_64-apple-darwin15.3.0

julia> @code_native Base.Threads.atomic_or!(Base.Threads.Atomic{Int128}(1),Int128(5))
LLVM ERROR: Program used external function '___sync_fetch_and_or_16' which could not be resolved!
~/julia
@yuyichao
Copy link
Contributor

Llvm emits a function call for that?

@yuyichao
Copy link
Contributor

Oh i see, it's probably caused by the generic arch. size of the Integer.

@vtjnash
Copy link
Member Author

vtjnash commented Jan 27, 2016

yes, it's the combination of being a generic arch and i128 (and expecting that compiler-rt will exist). i guess i opened the issue so that nobody will be particularly surprised when I open a PR for it.

@yuyichao
Copy link
Contributor

I think people will not be surprised if the PR includes tests for these functions =).

@vtjnash
Copy link
Member Author

vtjnash commented Jan 28, 2016

looks like the is actually an upstream bug (__sync instead of __atomic) – well, that and this particualr support code has been disabled for a couple years llvm-mirror/compiler-rt@fa3eee4

@JeffBezanson JeffBezanson added the upstream The issue is with an upstream dependency, e.g. LLVM label Jan 28, 2016
@Keno
Copy link
Member

Keno commented Jan 28, 2016

There was a thread on llvm dev abouty sync vs atomic today.

@Keno Keno closed this as completed Jan 28, 2016
@Keno Keno reopened this Jan 28, 2016
@eschnett
Copy link
Contributor

All modern Intel CPUs have the cmpxchg16b instruction. If LLVM can generate this instruction, then presumably it won't need to emit a call to ___sync_fetch_and_or_16. So maybe the solution is to use a target architecture that is slightly less generic than generic? This would in effect increase the minimum hardware required to run a thread-enabled Julia.

I also hear that "The 64-bit version of Windows 8.1 requires this feature" https://en.wikipedia.org/wiki/X86-64.

@eschnett
Copy link
Contributor

I confirm that this patch

$ git diff
diff --git a/src/codegen.cpp b/src/codegen.cpp
index 284ae89..e9a40ac 100644
--- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -5802,6 +5802,8 @@ static inline SmallVector<std::string,10> getTargetFeatures() {
 #ifdef V128_BUG
   HostFeatures["avx"] = false;
 #endif
+  // Require cx16 (cmpxchg16b)
+  HostFeatures["cx16"] = true;
 #endif

   // Figure out if we know the cpu_target

resolves the issue.

eschnett added a commit to eschnett/julia that referenced this issue Feb 24, 2016
This makes 128-bit atomics work on Intel. Without this feature, LLVM does not always know how to generate the respective code.

The CPU feature `cx16` describes whether the CPU supports the `cmpxchg16b` instruction. All modern Intel CPUs support this feature; see the discussion in JuliaLang#14818.

When Julia generates code for a `native` 64-bit CPU, this flag is already set correctly. However, when Julia generates code for either a 32-bit or a `generic` Intel CPU, then LLVM assumes pessimistically that this feature is not present. According to Wikipedia <https://en.wikipedia.org/wiki/X86-64>, this is only relevant for "early AMD64 processors", and "the 64-bit version of Windows 8.1 requires the instruction". I thus suggest to require this instruction as well when threading is enabled.

The alternative is to disable support for 128-bit atomics. The generic CPU target is apparently specified at many occasions, including for 32-bit Intel CPUs and in Travis.

Closes JuliaLang#14818.
eschnett added a commit to eschnett/julia that referenced this issue Mar 6, 2016
This makes 128-bit atomics work on Intel. Without this feature, LLVM does not always know how to generate the respective code.

The CPU feature `cx16` describes whether the CPU supports the `cmpxchg16b` instruction. All modern Intel CPUs support this feature; see the discussion in JuliaLang#14818.

When Julia generates code for a `native` 64-bit CPU, this flag is already set correctly. However, when Julia generates code for either a 32-bit or a `generic` Intel CPU, then LLVM assumes pessimistically that this feature is not present. According to Wikipedia <https://en.wikipedia.org/wiki/X86-64>, this is only relevant for "early AMD64 processors", and "the 64-bit version of Windows 8.1 requires the instruction". I thus suggest to require this instruction as well when threading is enabled.

The alternative is to disable support for 128-bit atomics. The generic CPU target is apparently specified at many occasions, including for 32-bit Intel CPUs and in Travis.

Closes JuliaLang#14818.
@eschnett
Copy link
Contributor

eschnett commented Mar 6, 2016

I believe this was corrected by #15219.

@eschnett
Copy link
Contributor

eschnett commented Mar 7, 2016

Unfortunately, #15219 only corrects this for 64-bit Intel systems, not for 32-bit systems.

@vtjnash vtjnash reopened this Mar 7, 2016
@yuyichao
Copy link
Contributor

Looks like llvm-svn have some issue that might be related? http://buildbot.e.ip.saba.us:8010/builders/nightly_llvmsvn-x64/builds/196/steps/make%20testall/logs/stdio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream The issue is with an upstream dependency, e.g. LLVM
Projects
None yet
Development

No branches or pull requests

5 participants