On 13/01/17 18:37, Emil Velikov wrote:
On 11 January 2017 at 19:19, Jose Fonseca <jfons...@vmware.com> wrote:
On 10/01/17 15:54, Emil Velikov wrote:
On 6 January 2017 at 17:35, Wu Zhen <wuz...@jidemail.com> wrote:
From: WuZhen <wuz...@jidemail.com>
since (cf410574 gallivm: Make MCJIT a runtime optioni.), llvmpipe assume
MCJIT is available on x86(_64). this is not the case for android prior to
M.
Wu Zhen, what exactly is the issue you're getting - build or link-time
error ?
Looking at the hunk [1] in the offending commit makes me wonder.
- Why do we call LLVMLinkInJIT() even if one selects MCJIT via the env
var.
- Why do we always call LLVMLinkInMCJIT regardless of a) if we've
build against old LLVM and b) the env var.
Jose, shouldn't we honour the above ? One way that comes to mind is to
have USE_MCJIT always as static variable. Then we can guard the
debug_get_bool_option() override with the current LLVM_VERSION/ARCH
heuristics while preserving original invocation.
if (USE_MCJIT) // use lowercase name since it's not a macro ?
LLVMLinkInMCJIT();
else
LLVMLinkInJIT();
Thanks
Emil
[1]
@@ -385,18 +382,18 @@ lp_build_init(void)
if (gallivm_initialized)
return TRUE;
+ LLVMLinkInMCJIT();
+#if !defined(USE_MCJIT)
+ USE_MCJIT = debug_get_bool_option("GALLIVM_MCJIT", 0);
+ LLVMLinkInJIT();
+#endif
+
#ifdef DEBUG
gallivm_debug = debug_get_option_gallivm_debug();
#endif
lp_set_target_options();
-#if USE_MCJIT
- LLVMLinkInMCJIT();
-#else
- LLVMLinkInJIT();
-#endif
-
USE_MCJIT used to be a statically define macro, but it's now it can also be
runtime boolean.
We require LLVM 3.3, and MCJIT has been available since then, so there was
no reason not to link.
Android seems a new beast: it has LLVM 3.3 but not MCJIT??
The Android discussion aside I was trying to point out that the commit
in question does more than making the compile time decision run-time
one.
Before the commit - LLVMLinkInMCJIT() was executed only when USE_MCJIT
is set, and after it's executed regardless. On the LLVMLinkInJIT front
- we seem to execute it even if the user has requested USE_MCJIT. I'm
either missing something here, or things look nasty/wrong ?
Thanks
Emil
Note that LLVMLinkInMCJIT() is a no-op at runtime. (At least it was
went I last looked at this.) And the purpose of using LLVMLinkInMCJIT
is merely to ensure that MCJIT library gets linked (otherwise trying to
enable mcjit would fail.)
Which is precisely the objective here: in order to potentially enable
the use MCJIT at runtime, the library needs to be statically linked.
It's not even necessary to actually call LLVMLinkInMCJIT() at runtime,
but it's important that LLVMLinkInMCJIT call doesn't get optimized away.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
