On 18/04/16 13:27, Emil Velikov wrote:
Hi Jose,
On 18 April 2016 at 10:14, Jose Fonseca <jfons...@vmware.com> wrote:
Instead of LLVM C++ interfaces.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index c1e262b..37e2f08 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -519,9 +519,11 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
/*
* MCJIT works on Windows, but currently only through ELF object
format.
*/
- std::string targetTriple = llvm::sys::getProcessTriple();
- targetTriple.append("-elf");
- unwrap(M)->setTargetTriple(targetTriple);
+# ifdef _WIN64
+ LLVMSetTarget(M, "x86_64-pc-win32-elf");
+# else
+ LLVMSetTarget(M, "i686-pc-win32-elf");
+# endif
I've noticed that you're using LLVM_HOST_TRIPLE in patch 7/9. Wouldn't
it be better to use it here as well ?
+ LLVMSetTarget(M, LLVM_HOST_TRIPLE "-elf");
Thanks for taking a look.
It's a good remark.
Surprisingly LLVM uses different LLVM_HOST_TRIPLE for MinGW/MSVC:
$ grep LLVM_HOST_TRIPLE */llvm-*/include
mingw32/llvm-3.3.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"i686-pc-mingw32"
mingw32/llvm-3.4.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"i686-pc-mingw32"
mingw64/llvm-3.3.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"x86_64-w64-mingw32"
mingw64/llvm-3.4.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"x86_64-w64-mingw32"
msvc32/llvm-3.3.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"i686-pc-win32"
msvc32/llvm-3.4.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"i686-pc-win32"
msvc64/llvm-3.3.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"x86_64-pc-win32"
msvc64/llvm-3.4.1/include/llvm/Config/config.h:#define LLVM_HOST_TRIPLE
"x86_64-pc-win32"
I'm not sure if this will matter (ie, will make LLVM behave internally
slightly differently, using slightly different conventions), but I
rather not take any chances and have MinGW match MSVC, for good or bad.
I'll add a comment explaining this though. (And I should find a way to
achieve the same on the old-JIT path too.)
That aside I'm really glad to see mesa (modulo swr) no longer using
the unstable LLVM C++ API.
Still not quite there, but yes that's indeed the hope.
> Perhaps at some point we could port these
to normal C and make gallivm 'C++ free' ;-)
There's no much use of C++ left indeed, and at some point might as well
remove it completely.
Would this make gallivm/LLVM more appealing to Intel?
There's a lot of places in Mesa where JIT makes sense. Particularly
format conversion, where the space of
src-format/dest-format/cpu-capabilities is huge, and it's all
performance sensitive. Though I suppose with Vulkan that should rarely
be needed.
For my part, my personal goal is to eliminate
src/gallium/auxiliary/rtasm in the medium term. And I think should
remove src/mesa/x86/rtasm too.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
