llvm dev - Feb 2017 - [RFC] Queries for LLVM version

On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic
wrote:
> I am certainly willing to write up a patch to do this. I was hoping
> to get a few more responses/buy-in from the community.
> And honestly, I'd be interested to know if this can be back-ported to
> at least 4.0 if it gets accepted.
My *possible* use case is for identifying the version of llvm used to
compile shaders for AMD gpus. This information would be used with an
on-disk cache of compiled shaders allowing old cache items to be
ignored if llvm is upgraded.

One downside of this is there is no way to know if distros backport
fixes to llvm. If the version is not bumped then the a buggy cached
shader would continue to be used even after the distro makes the fix.

> 
> Now that I see that there's more interest in this than just my own,
> I'll put up a patch on Phabricator.
Cool, thanks!
> 
> On Wed, Feb 8, 2017 at 12:04 AM, Timothy Arceri via llvm-dev <llvm-de
> v at lists.llvm.org> wrote:
> > On 01/26/2017 12:45 AM, Nemanja Ivanovic via llvm-dev wrote:
> > > This has actually come up in the context of a JIT, but I think
> > that 
> > > having the functionality in general could be useful.
> > >
> > > Currently, there does not appear to be an API in LLVM to query
> > for 
> > > LLVM version information. In the particular context where this
> > came 
> > > up, LLVM is used as a shared library and various functionality
> > (and 
> > > bug fixes) used by the JIT is available in various LLVM versions.
> > So 
> > > it would be quite convenient to be able to dynamically determine
> > the 
> > > version that happens to be loaded.
> > >
> > > Honestly, I am not completely clear on what the best place for 
> > > something like this would be, but it appears that the following
> > seems 
> > > like a natural choice:
> > >
> > > llvm::VersionPrinter in lib/Support/CommandLine.cpp already
> > queries 
> > > this data so it might make sense for it to expose the following
> > API's 
> > > (as part of VersionPrinter, accessed through the instance):
> > > llvm::cl::getVersionMajor()
> > > llvm::cl::getVersionMinor()
> > > llvm::cl::getVersionPatch()
> > 
> > Hi,
> > 
> > I'm also interested in querying this at runtime. Has there been
any
> > patches submitted for this yet?
> > 
> > Thanks,
> > Tim
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > 
> 
>

> On Feb 7, 2017, at 5:44 PM, Timothy Arceri via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote:
>> I am certainly willing to write up a patch to do this. I was hoping
>> to get a few more responses/buy-in from the community.
>> And honestly, I'd be interested to know if this can be back-ported
to
>> at least 4.0 if it gets accepted.
> 
> My *possible* use case is for identifying the version of llvm used to
> compile shaders for AMD gpus. This information would be used with an
> on-disk cache of compiled shaders allowing old cache items to be
> ignored if llvm is upgraded.
> 
> One downside of this is there is no way to know if distros backport
> fixes to llvm. If the version is not bumped then the a buggy cached
> shader would continue to be used even after the distro makes the fix.
This is exactly why we don’t use this kind of versioning: it is
fragile/unreliable.

— 
Mehdi

> 
> 
>> 
>> Now that I see that there's more interest in this than just my own,
>> I'll put up a patch on Phabricator.
> 
> Cool, thanks!
> 
>> 
>> On Wed, Feb 8, 2017 at 12:04 AM, Timothy Arceri via llvm-dev
<llvm-de
>> v at lists.llvm.org> wrote:
>>> On 01/26/2017 12:45 AM, Nemanja Ivanovic via llvm-dev wrote:
>>>> This has actually come up in the context of a JIT, but I think
>>> that 
>>>> having the functionality in general could be useful.
>>>> 
>>>> Currently, there does not appear to be an API in LLVM to query
>>> for 
>>>> LLVM version information. In the particular context where this
>>> came 
>>>> up, LLVM is used as a shared library and various functionality
>>> (and 
>>>> bug fixes) used by the JIT is available in various LLVM
versions.
>>> So 
>>>> it would be quite convenient to be able to dynamically
determine
>>> the 
>>>> version that happens to be loaded.
>>>> 
>>>> Honestly, I am not completely clear on what the best place for 
>>>> something like this would be, but it appears that the following
>>> seems 
>>>> like a natural choice:
>>>> 
>>>> llvm::VersionPrinter in lib/Support/CommandLine.cpp already
>>> queries 
>>>> this data so it might make sense for it to expose the following
>>> API's 
>>>> (as part of VersionPrinter, accessed through the instance):
>>>> llvm::cl::getVersionMajor()
>>>> llvm::cl::getVersionMinor()
>>>> llvm::cl::getVersionPatch()
>>> 
>>> Hi,
>>> 
>>> I'm also interested in querying this at runtime. Has there been
any
>>> patches submitted for this yet?
>>> 
>>> Thanks,
>>> Tim
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>> 
>> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

So Mehdi,
you're not in favour of providing this functionality then? Or just not in
favour of that use case?

On Wed, Feb 8, 2017 at 10:18 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> > On Feb 7, 2017, at 5:44 PM, Timothy Arceri via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote:
> >> I am certainly willing to write up a patch to do this. I was
hoping
> >> to get a few more responses/buy-in from the community.
> >> And honestly, I'd be interested to know if this can be
back-ported to
> >> at least 4.0 if it gets accepted.
> >
> > My *possible* use case is for identifying the version of llvm used to
> > compile shaders for AMD gpus. This information would be used with an
> > on-disk cache of compiled shaders allowing old cache items to be
> > ignored if llvm is upgraded.
> >
> > One downside of this is there is no way to know if distros backport
> > fixes to llvm. If the version is not bumped then the a buggy cached
> > shader would continue to be used even after the distro makes the fix.
>
> This is exactly why we don’t use this kind of versioning: it is
> fragile/unreliable.
>
> —
> Mehdi
>
>
> >
> >
> >>
> >> Now that I see that there's more interest in this than just my
own,
> >> I'll put up a patch on Phabricator.
> >
> > Cool, thanks!
> >
> >>
> >> On Wed, Feb 8, 2017 at 12:04 AM, Timothy Arceri via llvm-dev
<llvm-de
> >> v at lists.llvm.org> wrote:
> >>> On 01/26/2017 12:45 AM, Nemanja Ivanovic via llvm-dev wrote:
> >>>> This has actually come up in the context of a JIT, but I
think
> >>> that
> >>>> having the functionality in general could be useful.
> >>>>
> >>>> Currently, there does not appear to be an API in LLVM to
query
> >>> for
> >>>> LLVM version information. In the particular context where
this
> >>> came
> >>>> up, LLVM is used as a shared library and various
functionality
> >>> (and
> >>>> bug fixes) used by the JIT is available in various LLVM
versions.
> >>> So
> >>>> it would be quite convenient to be able to dynamically
determine
> >>> the
> >>>> version that happens to be loaded.
> >>>>
> >>>> Honestly, I am not completely clear on what the best place
for
> >>>> something like this would be, but it appears that the
following
> >>> seems
> >>>> like a natural choice:
> >>>>
> >>>> llvm::VersionPrinter in lib/Support/CommandLine.cpp
already
> >>> queries
> >>>> this data so it might make sense for it to expose the
following
> >>> API's
> >>>> (as part of VersionPrinter, accessed through the
instance):
> >>>> llvm::cl::getVersionMajor()
> >>>> llvm::cl::getVersionMinor()
> >>>> llvm::cl::getVersionPatch()
> >>>
> >>> Hi,
> >>>
> >>> I'm also interested in querying this at runtime. Has there
been any
> >>> patches submitted for this yet?
> >>>
> >>> Thanks,
> >>> Tim
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170208/7a5b89e8/attachment.html>