Latest Julia fails to build with LLVM-svn on Fedora 27 (x86-64).
My Make.user
contains:
MARCH=native
LLVM_VER=svn
After fixing (I hope) some superficial API changes:
diff --git a/src/codegen.cpp b/src/codegen.cpp
index f4599b6375..fc3c4742b2 100644
--- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -38,7 +38,7 @@
#include <functional>
// target machine computation
-#include <llvm/Target/TargetSubtargetInfo.h>
+#include <llvm/CodeGen/TargetSubtargetInfo.h>
#include <llvm/Support/TargetRegistry.h>
#include <llvm/Target/TargetOptions.h>
#include <llvm/Support/Host.h>
diff --git a/src/disasm.cpp b/src/disasm.cpp
index 3aea615173..94159247f9 100644
--- a/src/disasm.cpp
+++ b/src/disasm.cpp
@@ -685,7 +685,7 @@ static void jl_dump_asm_internal(
CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
#if JL_LLVM_VERSION >= 40000
MCTargetOptions Options;
- MAB = TheTarget->createMCAsmBackend(*MRI, TripleName, cpu, Options);
+ MAB = TheTarget->createMCAsmBackend(*STI, *MRI, Options);
#else
MAB = TheTarget->createMCAsmBackend(*MRI, TripleName, cpu);
#endif
diff --git a/src/intrinsics.cpp b/src/intrinsics.cpp
index ecbf1fb53a..76d043d28d 100644
--- a/src/intrinsics.cpp
+++ b/src/intrinsics.cpp
@@ -753,7 +753,7 @@ struct math_builder {
if (jl_options.fast_math != JL_OPTIONS_FAST_MATH_OFF &&
(always_fast ||
jl_options.fast_math == JL_OPTIONS_FAST_MATH_ON)) {
- fmf.setUnsafeAlgebra();
+ fmf.setFast();
}
#if JL_LLVM_VERSION >= 50000
if (contract)
diff --git a/src/llvm-muladd.cpp b/src/llvm-muladd.cpp
index a8b635f9c3..8527e5b4f8 100644
--- a/src/llvm-muladd.cpp
+++ b/src/llvm-muladd.cpp
@@ -91,14 +91,14 @@ bool CombineMulAdd::runOnFunction(Function &F)
it++;
switch (I.getOpcode()) {
case Instruction::FAdd: {
- if (!I.hasUnsafeAlgebra())
+ if (!I.isFast())
continue;
checkCombine(m, &I, I.getOperand(0), I.getOperand(1), false, false) ||
checkCombine(m, &I, I.getOperand(1), I.getOperand(0), false, false);
break;
}
case Instruction::FSub: {
- if (!I.hasUnsafeAlgebra())
+ if (!I.isFast())
continue;
checkCombine(m, &I, I.getOperand(0), I.getOperand(1), true, false) ||
checkCombine(m, &I, I.getOperand(1), I.getOperand(0), true, true);
diff --git a/src/llvm-simdloop.cpp b/src/llvm-simdloop.cpp
index 87f4d953b5..54de27989e 100644
--- a/src/llvm-simdloop.cpp
+++ b/src/llvm-simdloop.cpp
@@ -152,7 +152,7 @@ void LowerSIMDLoop::enableUnsafeAlgebraIfReduction(PHINode *Phi, Loop *L) const
}
for (chainVector::const_iterator K=chain.begin(); K!=chain.end(); ++K) {
DEBUG(dbgs() << "LSL: marking " << **K << "\n");
- (*K)->setHasUnsafeAlgebra(true);
+ (*K)->setFast(true);
}
}
... the build fails with the following error:
$ make cleanall
$ make
[...]
/home/m/software/juliabuild/julia/base/precompile.jl
Incorrect number of arguments passed to called function!
call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 40, i32 0, i1 false)
LLVM ERROR: Broken function found, compilation aborted!
* This error is usually fixed by runningmake clean
. If the error persists, trymake cleanall
.
make[1]: [Makefile:221: /home/m/software/juliabuild/julia/usr/lib/julia/sys.o] Error 1
make: * [Makefile:101: julia-sysimg-release] Error 2
It seems likely that this is caused by a recent change in the LLVM memset
and related intrinsics (https://reviews.llvm.org/rL322965). However, I cannot figure out what exactly is wrong, since there don't seem to be any explicit calls of @llvm.memset.*
in the codebase.
Just so you're aware, Julia isn't expected to work with arbitrary development snapshots of LLVM. That said, we do generally try to keep it working as LLVM gets updated, so thank you for the report.
However, I cannot figure out what exactly is wrong, since there don't seem to be any explicit calls of @llvm.memset.* in the codebase.
Grep the source for Intrinsic::memset
to see where they are being introduced.
Thanks, Keno!
The one offending instance seems to be in "src/llvm-late-gc-lowering.cpp". After removing the alignment argument, Julia builds and tests pass (mostly, with 2 failures in SuiteSparse and 1 in REPL).
Most helpful comment
Just so you're aware, Julia isn't expected to work with arbitrary development snapshots of LLVM. That said, we do generally try to keep it working as LLVM gets updated, so thank you for the report.