[Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Emil Velikov]

On 17 October 2016 at 08:56, Michel Dänzer <michel at daenzer.net> wrote:
> On 14/10/16 07:02 PM, Emil Velikov wrote:
>> On 14 October 2016 at 09:45, Michel Dänzer <michel at daenzer.net> wrote:
>>> On 14/10/16 05:14 PM, Emil Velikov wrote:
>>>> On 14 October 2016 at 01:45, Michel Dänzer <michel at daenzer.net> wrote:
>>>>> On 13/10/16 07:14 PM, Emil Velikov wrote:
>>>>>> On 13 October 2016 at 04:07, Michel Dänzer <michel at daenzer.net> wrote:
>>>>>>> On 13/10/16 03:37 AM, Tobias Droste wrote:
>>>>>>>> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
>>>>>>>>>>
>>>>>>>>>> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
>>>>>>>>>> +LLVM_VERSION_REQUIRED_R600=3.6.0
>>>>>>>>>> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
>>>>>>>>>
>>>>>>>>> There's a small related gotcha: as-is at build time we get the
>>>>>>>>> different codepaths thus, as people build against shared LLVM (hello
>>>>>>>>> Archlinux, I'm looking at you) and update their LLVM without
>>>>>>>>> rebuilding mesa (Arch I'm looking at you again) things go funny.
>>>>>>>
>>>>>>> What exactly happened there? LLVM upstream generates shared libraries
>>>>>>> named libLLVM-<major>.<minor>.so*, so it shouldn't be possible for a
>>>>>>> simple LLVM package update to break Mesa, unless Arch did something
>>>>>>> really stupid.
>>>>>>>
>>>>>> The issue is not specific to Arch, but anyone who links against shared LLVM.
>>>>>>
>>>>>> Here is another take on it:
>>>>>> At least swr and r600/radeonsi depend at _build_ time on the _patch_
>>>>>> version of LLVM. The latter of which is not part of the DSO name. Thus
>>>>>> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
>>>>>> "3.9.x" codepath even though you are be using "3.9.y" LLVM.
>>>>>
>>>>> That should be fine, since 3.9.y is backwards compatible with 3.9.x.
>>>>>
>>>>> Debian doesn't automatically recompile Mesa in such cases either, and I
>>>>> haven't seen any problems there because of that.
>>>>>
>>>>> So, what exactly was the problem?
>>>>>
>>>> Just grep through for LLVM_.*PATCH and you'll see it. Portable code
>>>> should not check that at compile time.
>>>
>>> This is getting a bit annoying... Please explicitly say what you think
>>> is a problem, especially after being asked to do so multiple times.
>>>
>> AFAICT picking on like an old bat can be annoying, so I've tried to avoid it.
>> Regardless, as per your request:
>
> Thank you.
>
>
>> * src/gallium/drivers/radeon/r600_pipe_common.c
>> No actual bug, yet misleading.
>
> If you want to call it that... I'd say this can be useful for detecting
> the problems you're thinking of. :)
>
>
On the contrary, for example:
Building against shared llvm 3.6.0, later one updates to 3.6.2.

Mesa is not rebuild, thus the above message says "3.6.0" and they
don't get any tessellation.
Then they check with their package/install - Why is Mesa showing
3.6.0, I have 3.6.2 installed. Should I reinstall LLVM, are there any
parts of 3.6.0 still around ?"

This in itself is because people don't expect that one should rebuild
package X when one its dependencies gets a patch version change.

>> * src/gallium/drivers/radeonsi/si_pipe.c
>> Update to 3.6.2+, still missing tessellation unless you rebuild mesa.
>
> Right, exactly the same as with static linking.
>
>> The latter bug in itself.
>
> Not sure what you mean by that.
>
>
>> Downgrade - TBD, depending on the (fixed) LLVM bugs.
>
> Building against one version of LLVM and then downgrading the shared
> library to an older version is indeed the only case we're currently not
> handling gracefully. It should be rather rare though.
>
>
>> src/gallium/drivers/swr/rasterizer/jitter/scripts/gen_llvm_ir_macros.py
>> Reversed argument order. No issues if the whole things gets inlined
>> into mesa, fun experience otherwise.
>
> If the newer LLVM version doesn't work with code compiled for the older
> version, I'd consider that an LLVM bug.
>
>
>> Using a runtime check for shared libs [...] the "better" choice, imho.
>
> Right, that would probably be the best solution. Any volunteers to make
> it happen?
>
More than happy to make it work on mesa side. Since my LLVM experience
is virtually not there, perhaps we can bribe someone who already knows
their way around  ;-)

Tom, can you forward the request to fellow LLVM developers:
Since LLVM has the feature to provide a shared library/ies, it would
be great to have an API which provides the major/minor/patch version.
The last one being the one we really want here.
This way user which links against the shared lib(s) can query the
version and act accordingly - be that apply local workarounds or
disable certain functionality.

>
>> That or just bump the requirement ?
>
> That wouldn't protect against the shared library being downgraded to an
> older version.
>
Almost. AFAICT Mesa has (had for a long time) the implicit agreement
that the build-time requirements are identical to the run-time ones.

If people use a lower [runtime] versions, things will explode in many
places. This is not specific/isolated to LLVM.

Thanks
Emil