search for: module_code_version

> Reading the bitcode reader while working on another issues I found > that we already have a version in the bitcode itself (not the darwin > wrapper) and it is used! It is stored with the > bitc::MODULE_CODE_VERSION. It is used to select relative ids, which > impacts the entire bitcode, and so it makes sense to be based on a > version. > > If we ever have a new feature that could not be otherwise detected, > bumping the number is a reasonable way of making sure old versions of > llvm will re...

On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> > Does Apple support library/middleware providers shipping bitcode instead >> >>> > of object code? >>> >>> No. >>> >> >> Are there ever any plans to do so?

...,GLOBALVAR,ALIAS,IFUNC,COMDAT} > records would change so that their first operand would specify their names > with a byte offset into the string table. (To allow for backwards > compatibility, I would increment the bitcode version.) > > > I assume you mean the EPOCH? > No, the MODULE_CODE_VERSION. http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822 It isn't clear to me why we have both. > Here is what it would look like as bcanalyzer output: > > <MODULE_BLOCK> > <VERSION op0=2> > <COMDAT op0=0 ...> ; name = foo > <FUNCTION op...

...ck already, > I'm looking forward to seeing the updated patch. Thanks for tackling this > Jan! > > -Chris > Thanks for taking a look! I wasn't sure of better way to toggle this behavior at the module level vs the function level. The options I toyed with were: (a) bump MODULE_CODE_VERSION from 0 to 1 (b) add a new optional module code to identify the change (c) stick with the approach in the first patch, which used a new function block ID value, then check that all the function blocks uniformly have the newer ID instead of mix of the old and new. for option (a) there hasn'...

...t; records would change so that their first operand would specify their names >> with a byte offset into the string table. (To allow for backwards >> compatibility, I would increment the bitcode version.) >> >> >> I assume you mean the EPOCH? >> > > No, the MODULE_CODE_VERSION. > http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822 > It isn't clear to me why we have both. > > >> Here is what it would look like as bcanalyzer output: >> >> <MODULE_BLOCK> >> <VERSION op0=2> >> <COMDAT op0=0 ...&g...

...ost concerned about is this: > > > > - We as a vendor publish toolchain #12 based on SVN r250000. > > - During subsequent LLVM development, changes happen (!). > > For example, a new key letter 'g' in the Data Layout. This is > > not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged. > > - We as a vendor publish toolchain #13 based on SVN r300000. > > - Some middleware provider publishes libIncrediblyUseful.bc built > > using spiffy new toolchain #13. > > - Some hapless game developer tries to use libIncrediblyUseful.bc > > but is...

Where is the testing that proves all this works? Patches welcome… Now, I've known QA people who break software in two minutes as naturally as breathing; I do not have that skill. Given that I came up with *anything* in two minutes, I am not filled with confidence. Right now I'm in the middle of un-borking my bots in the wake of the upstream "improvements" to GetSVN.cmake, but

...t; records would change so that their first operand would specify their names >> with a byte offset into the string table. (To allow for backwards >> compatibility, I would increment the bitcode version.) >> >> >> I assume you mean the EPOCH? >> > > No, the MODULE_CODE_VERSION. > http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822 > It isn't clear to me why we have both. > > >> Here is what it would look like as bcanalyzer output: >> >> <MODULE_BLOCK> >> <VERSION op0=2> >> <COMDAT op0=0 ...&g...

> Thanks for taking a look! I wasn't sure of better way to toggle this > behavior at the module level vs the function level. The options I toyed > with were: > > (a) bump MODULE_CODE_VERSION from 0 to 1 > (b) add a new optional module code to identify the change > (c) stick with the approach in the first patch, which used a new function > block ID value, then check that all the function blocks uniformly have the > newer ID instead of mix of the old and new. > > &g...

On Sep 25, 2012, at 5:08 PM, Jan Voung <jvoung at chromium.org> wrote: > Hi all, > > I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E

...ost concerned about is this: > > > > - We as a vendor publish toolchain #12 based on SVN r250000. > > - During subsequent LLVM development, changes happen (!). > > For example, a new key letter 'g' in the Data Layout. This is > > not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged. > > - We as a vendor publish toolchain #13 based on SVN r300000. > > - Some middleware provider publishes libIncrediblyUseful.bc built > > using spiffy new toolchain #13. > > - Some hapless game developer tries to use libIncrediblyUseful.bc > > but is...

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute