<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 8, 2017, at 7:51 AM, Nemanja Ivanovic <<a href="mailto:nemanja.i.ibm@gmail.com" class="">nemanja.i.ibm@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">So Mehdi,<br class=""></div>you're not in favour of providing this functionality then? </div></div></blockquote><div><br class=""></div><div>I’m not against the functionality, but I’m not sure the API is the right one for the use-case.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Or just not in favour of that use case?<br class=""></div></div></blockquote><div><br class=""></div><div>The use-case (object cache) makes perfect sense, but I wouldn’t use this API.</div><div>I’d like use a `const char *getLLVMVersion()` API that would be documented as returning an opaque string representing the LLVM version.</div><div>The reason to return an opaque string is to prevent (not encourage…) users to parse it. It could return something like “LLVM 4.0.0svn(r12345)”.</div><div>Using this as part of your cache key makes it more robust to switching a given version of the compiler.</div><div><br class=""></div><div>But ultimately, if I had to build such a caching system*, I’d likely do it upstream in LLVM and design the API to such that it would “just work” for my shader driver and could be maintained/improved by the community and reused by other users.</div><div><br class=""></div><div>* <a href="https://github.com/llvm-mirror/llvm/blob/master/lib/LTO/Caching.cpp" class="">https://github.com/llvm-mirror/llvm/blob/master/lib/LTO/Caching.cpp</a> <a href="https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/CachePruning.h" class="">https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/CachePruning.h</a> </div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 8, 2017 at 10:18 AM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Feb 7, 2017, at 5:44 PM, Timothy Arceri via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
><br class="">
> On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote:<br class="">
>> I am certainly willing to write up a patch to do this. I was hoping<br class="">
>> to get a few more responses/buy-in from the community.<br class="">
>> And honestly, I'd be interested to know if this can be back-ported to<br class="">
>> at least 4.0 if it gets accepted.<br class="">
><br class="">
> My *possible* use case is for identifying the version of llvm used to<br class="">
> compile shaders for AMD gpus. This information would be used with an<br class="">
> on-disk cache of compiled shaders allowing old cache items to be<br class="">
> ignored if llvm is upgraded.<br class="">
><br class="">
> One downside of this is there is no way to know if distros backport<br class="">
> fixes to llvm. If the version is not bumped then the a buggy cached<br class="">
> shader would continue to be used even after the distro makes the fix.<br class="">
<br class="">
</span>This is exactly why we don’t use this kind of versioning: it is fragile/unreliable.<br class="">
<br class="">
—<br class="">
<span class="HOEnZb"><font color="#888888" class="">Mehdi<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
<br class="">
><br class="">
><br class="">
>><br class="">
>> Now that I see that there's more interest in this than just my own,<br class="">
>> I'll put up a patch on Phabricator.<br class="">
><br class="">
> Cool, thanks!<br class="">
><br class="">
>><br class="">
>> On Wed, Feb 8, 2017 at 12:04 AM, Timothy Arceri via llvm-dev <llvm-de<br class="">
>> <a href="mailto:v@lists.llvm.org" class="">v@lists.llvm.org</a>> wrote:<br class="">
>>> On 01/26/2017 12:45 AM, Nemanja Ivanovic via llvm-dev wrote:<br class="">
>>>> This has actually come up in the context of a JIT, but I think<br class="">
>>> that<br class="">
>>>> having the functionality in general could be useful.<br class="">
>>>><br class="">
>>>> Currently, there does not appear to be an API in LLVM to query<br class="">
>>> for<br class="">
>>>> LLVM version information. In the particular context where this<br class="">
>>> came<br class="">
>>>> up, LLVM is used as a shared library and various functionality<br class="">
>>> (and<br class="">
>>>> bug fixes) used by the JIT is available in various LLVM versions.<br class="">
>>> So<br class="">
>>>> it would be quite convenient to be able to dynamically determine<br class="">
>>> the<br class="">
>>>> version that happens to be loaded.<br class="">
>>>><br class="">
>>>> Honestly, I am not completely clear on what the best place for<br class="">
>>>> something like this would be, but it appears that the following<br class="">
>>> seems<br class="">
>>>> like a natural choice:<br class="">
>>>><br class="">
>>>> llvm::VersionPrinter in lib/Support/CommandLine.cpp already<br class="">
>>> queries<br class="">
>>>> this data so it might make sense for it to expose the following<br class="">
>>> API's<br class="">
>>>> (as part of VersionPrinter, accessed through the instance):<br class="">
>>>> llvm::cl::getVersionMajor()<br class="">
>>>> llvm::cl::getVersionMinor()<br class="">
>>>> llvm::cl::getVersionPatch()<br class="">
>>><br class="">
>>> Hi,<br class="">
>>><br class="">
>>> I'm also interested in querying this at runtime. Has there been any<br class="">
>>> patches submitted for this yet?<br class="">
>>><br class="">
>>> Thanks,<br class="">
>>> Tim<br class="">
>>> ______________________________<wbr class="">_________________<br class="">
>>> LLVM Developers mailing list<br class="">
>>> <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
>>><br class="">
>><br class="">
>><br class="">
> ______________________________<wbr class="">_________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>