[llvm-dev] bitcode versioning

[Martin J. O'Riordan via llvm-dev]

Actually, I wasn't requesting additional functionality of a version resource, rather I was asking "if you were also providing an API to it".  I guess the answer is that the proposal does not include a programmatic abstraction or API.  This is not a problem, I can parse arbitrary strings easily enough.

> >  o  Get the major number
> >  o  Get the minor number
> >  o  Get the patch number
>
> This would force a specific model for the version, which we didn’t want.

These are just examples for illustrating my response, not intended as specific API requests - an API for the actual implemented version resource would of course provide its own notion of the content of the resource and would naturally derive from that implementation.

Thanks for clarifying this.

	MartinO

-----Original Message-----
From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] 
Sent: 12 December 2015 02:14
To: Martin J. O'Riordan <martin.oriordan at movidius.com>
Cc: Manuel Rigger <rigger.manuel at gmail.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] bitcode versioning


> On Dec 11, 2015, at 6:13 AM, Martin J. O'Riordan <martin.oriordan at movidius.com> wrote:
> 
> Hi Mehdi and my apologies for the delay in responding - the day job got in the way :-)
> 
> Our target is still out-of-tree so my reasons for extending the IR would be eliminated if we were a proper part of LLVM, which I would like to do when the time is right for us.
> 
> My extensions are quite simple really, and I expect that they will be wanted in the TRUNK sometime anyway.
> 
> At the moment I only have one remaining change which is to add 'v16f16' to the set of IR types.  Previously I had several other FP16 vector types added, but over the past few iterations of LLVM my changes have been gradually made redundant because others have added them formally to the source.  I expect that 'v16f16' will go this way too allowing me to have an unaltered IR.
> 
> But the problem I have faced with making the changes, is that my LLVM cannot accept the BC produced by another version (and vice versa), not even the official version, because the placement of the types in the enumeration is very particular and changes the indices for all the subsequent values.
> 
> I had often thought it would be helpful if the BC (and LL for that matter) had a version resource of some kind, that would allow me to see that the incoming IR was produced by the official unchanged LLVM, and then I could have placed a translation in the loader that would remap the indices to the ones expect by my back-end.
> 
> When you proposed the addition of a version resource, I was thinking that rather than each target adding parsing code for it, it would be better and more transparent for it to appear as a "Version Resource Object" that I could query for simple things like:
> 
>  o  Get the major number
>  o  Get the minor number
>  o  Get the patch number

This would force a specific model for the version, which we didn’t want.

>  o  Is it extended? and if "yes":
>     -  Get the vendor ID (could be a string)
>     -  Get the vendor specific extension number
> 
> And this is really what I mean by an API - essentially a simple object representing the version information.  For IR production/emission, there would need to be a 'setter' interface too.

This is what we do, but using the string only. 
The “setter” is compile time (LLVM_VERSION probably), we patch the bitcode write internally 

> 
> This would allow me to make my extensions, yet be in a position to more robustly accept BC or LL from other sources.  In particular I should be able to remap IR coming from a well-known point-release of LLVM, and also be able to detect, diagnose and reject input from sources I don't recognise (at the moment it just causes a crash).

The string content is predictable: if it will begin with “LLVM3.8.0” or “LLVM3.9.0”, etc. So you should be able to do exactly what you want.
The bitcode produced by our binaries has a very different string, and we use this information to identify the producer as well.
What’s missing?

— 
Mehdi