[Mesa-dev] [PATCH 4/8] android: fix llvmpipe build

[Jose Fonseca]

On 13/01/17 18:37, Emil Velikov wrote:
> On 11 January 2017 at 19:19, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 10/01/17 15:54, Emil Velikov wrote:
>>>
>>> On 6 January 2017 at 17:35, Wu Zhen <wuzhen at jidemail.com> wrote:
>>>>
>>>> From: WuZhen <wuzhen at 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