[LLVMdev] [PATCH] -emit-bitcode-version

[Chris Lattner]

On Nov 9, 2012, at 2:35 PM, Joe Abbey <jabbey at arxan.com> wrote:
> Thanks for the reply.  The talk has  been quite beneficial in connecting me with Nico Weber and Stephen Hines on this problem space.  Thanks again for enabling the community with the developers' conference, and trying out lightning talks. 
> 
>> 1. This will (over time) accrete a ton of old gunk in the bitcode writer, and also slow down progress.
> 
> Well there's actually three layers of compatibility, possibly more. 
> 
> 1. The LLVM API
> 
> The LLVM API is simply a cost I have to eat every now and then when moving from version n to n+1.  And after our leap from 2.8 -> 3.0 the API layer has been generally stable.  A couple refactors here and there in recent days, like Attributes, but nothing major.  I'm trying to assess our internal usage and ponder an API layer which abstracts LLVM from our tool.  Still weighing pros and cons on that.  

Makes sense.

> 2. IR
> 
> Since 3.0 it's been very stable, there was a blip in 3.1 to 3.2 where switch records changed but overall not the problem I faced with 2.8 to 3.0.  I don't see any way to provide IR compatibility.  If it happens to change we'll just have to roll with those punches. Pretty sure even an llvm-dis to llvm-as fails us. 

Yep, I do expect bitcode to settle down a bit now, except to support new IR features.  I don't know about everyone else, but I'm personally done fiddling with the bitcode encoding just or the sake of it ;-).  That was really the purpose of 3.0.

That said, there *are* new IR features being added.  For example, the recent discussion on llvmdev about modeling "fast math" properly on floating point operations will require new fields in bitcode.

As you know, bitcode was intentionally designed to be extensible going forward, so this shouldn't be a problem.  However, how would -emit-bitcode-version work if the IR is using some feature that cannot be encoded in the old format?  Silently dropping the IR information doesn't seem like a good approach.

> 3. Bitcode encoding
> 
> This one is a bit of a head scratcher.  The encoding offered 0 new features, and was a relatively arbitrary change. Yeah it saves 15% size, but it's completely optional.  And for a couple users with unique use-cases it breaks reading 3.2 written code for not a whole lot of gain. 
> 
> Turning this on and off doesn't add gunk or an unmaintainable path.  Maybe in a few months we try something more comprehensive like Espindola's SLEB suggestion.  What about the original use-abs-operands?  Do you think that what more reasonably scope this?
> 
> And so properly scoping my proposal I see that I don't want IR compatibility as much as I want encoding options.  So with that in mind maybe I need to go back to the drawing board and propose a BitcodeEncoder?BitcodeCompressor?

I can see where you're coming from here, this does seem like something that could be opt'ed into.  However, this is the least common sort of change that we see in the bitcode files.  Almost all of the churn we have is adding encodings for new IR features.

To be clear about this, I'm not strongly opposed to parameterizing the bitcode writer, but I want it to be done in a way that makes sense, and is likely to actually help going forward.

-Chris