<div dir="ltr">Would it make sense to:<br><ol><li>Provide the integer Major/Minor/Patch API's for use cases where the user wants to check that the loaded version is at least some version that contains a fix they're after</li><li>Provide a string API for the caching use case you outlined</li></ol></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 3:56 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Feb 8, 2017, at 7:51 AM, Nemanja Ivanovic <<a href="mailto:nemanja.i.ibm@gmail.com" target="_blank">nemanja.i.ibm@gmail.com</a>> wrote:</div><br class="m_6859429729845591090Apple-interchange-newline"><div><div dir="ltr"><div>So Mehdi,<br></div>you're not in favour of providing this functionality then? </div></div></blockquote><div><br></div></span><div>I’m not against the functionality, but I’m not sure the API is the right one for the use-case.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr">Or just not in favour of that use case?<br></div></div></blockquote><div><br></div></span><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></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></div><div>* <a href="https://github.com/llvm-mirror/llvm/blob/master/lib/LTO/Caching.cpp" target="_blank">https://github.com/llvm-<wbr>mirror/llvm/blob/master/lib/<wbr>LTO/Caching.cpp</a> <a href="https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/CachePruning.h" target="_blank">https://github.com/llvm-<wbr>mirror/llvm/blob/master/<wbr>include/llvm/Support/<wbr>CachePruning.h</a> </div><div><br></div><div>— </div><span class="HOEnZb"><font color="#888888"><div>Mehdi</div></font></span><div><div class="h5"><div><br></div><br><blockquote type="cite"><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 10:18 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Feb 7, 2017, at 5:44 PM, Timothy Arceri via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote:<br>
>> I am certainly willing to write up a patch to do this. I was hoping<br>
>> to get a few more responses/buy-in from the community.<br>
>> And honestly, I'd be interested to know if this can be back-ported to<br>
>> at least 4.0 if it gets accepted.<br>
><br>
> My *possible* use case is for identifying the version of llvm used to<br>
> compile shaders for AMD gpus. This information would be used with an<br>
> on-disk cache of compiled shaders allowing old cache items to be<br>
> ignored if llvm is upgraded.<br>
><br>
> One downside of this is there is no way to know if distros backport<br>
> fixes to llvm. If the version is not bumped then the a buggy cached<br>
> shader would continue to be used even after the distro makes the fix.<br>
<br>
</span>This is exactly why we don’t use this kind of versioning: it is fragile/unreliable.<br>
<br>
—<br>
<span class="m_6859429729845591090HOEnZb"><font color="#888888">Mehdi<br>
</font></span><div class="m_6859429729845591090HOEnZb"><div class="m_6859429729845591090h5"><br>
<br>
><br>
><br>
>><br>
>> Now that I see that there's more interest in this than just my own,<br>
>> I'll put up a patch on Phabricator.<br>
><br>
> Cool, thanks!<br>
><br>
>><br>
>> On Wed, Feb 8, 2017 at 12:04 AM, Timothy Arceri via llvm-dev <llvm-de<br>
>> <a href="mailto:v@lists.llvm.org" target="_blank">v@lists.llvm.org</a>> wrote:<br>
>>> On 01/26/2017 12:45 AM, Nemanja Ivanovic via llvm-dev wrote:<br>
>>>> This has actually come up in the context of a JIT, but I think<br>
>>> that<br>
>>>> having the functionality in general could be useful.<br>
>>>><br>
>>>> Currently, there does not appear to be an API in LLVM to query<br>
>>> for<br>
>>>> LLVM version information. In the particular context where this<br>
>>> came<br>
>>>> up, LLVM is used as a shared library and various functionality<br>
>>> (and<br>
>>>> bug fixes) used by the JIT is available in various LLVM versions.<br>
>>> So<br>
>>>> it would be quite convenient to be able to dynamically determine<br>
>>> the<br>
>>>> version that happens to be loaded.<br>
>>>><br>
>>>> Honestly, I am not completely clear on what the best place for<br>
>>>> something like this would be, but it appears that the following<br>
>>> seems<br>
>>>> like a natural choice:<br>
>>>><br>
>>>> llvm::VersionPrinter in lib/Support/CommandLine.cpp already<br>
>>> queries<br>
>>>> this data so it might make sense for it to expose the following<br>
>>> API's<br>
>>>> (as part of VersionPrinter, accessed through the instance):<br>
>>>> llvm::cl::getVersionMajor()<br>
>>>> llvm::cl::getVersionMinor()<br>
>>>> llvm::cl::getVersionPatch()<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I'm also interested in querying this at runtime. Has there been any<br>
>>> patches submitted for this yet?<br>
>>><br>
>>> Thanks,<br>
>>> Tim<br>
>>> ______________________________<wbr>_________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
>>><br>
>><br>
>><br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</div></div></blockquote></div><br></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div>