similar to: [LLVMdev] Bitcode format

Hi Joshua, On Mon, 2007-09-03 at 21:34 +0000, Joshua Haberman wrote: > Greetings, > > I am working on a project (unrelated to LLVM) that needed a > bytecode-like format. I found Bitcode and it seems to fit the bill > really nicely. > > I am writing an independent implementation of Bitcode in C (I really > want to keep my runtime pure C). In the process of doing this,

Reid Spencer <rspencer <at> reidspencer.com> writes: > Hi Joshua, Hi, thanks for the reply. > On Mon, 2007-09-03 at 21:34 +0000, Joshua Haberman wrote: > > I also have a few questions about the format: > > > > - it appears that the only magic number in the file is > > application-specific. This seems unfortunate, because it means that > >

I wrote in a few weeks ago about writing an independent implementation of Bitcode and updating the docs to be more complete. Attached is a patch to docs/BitCodeFormat.html that adds a lot of information that was previously only available by reading the source code. It also corrects some errors. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

Thanks for the review Rafael! Chris, did you want to take a look at the patch too? Thanks, - Jan On Wed, Oct 10, 2012 at 12:39 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 10 October 2012 15:15, Jan Voung <jvoung at chromium.org> wrote: > > Yes, I had about 133K hits for INST_PHI with a negative value, out of > 136K > > hits of any

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

Sorry if I was unclear. There are currently no “known incompatibilities” that I am aware of, although I fully admit to not being an expert on the topic. The idea is that we add versioning information to the bitcode so that if an issue were discovered, it could be easily detected and dealt with. Douglas Yung From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Friday, September 26, 2014 16:39

On Sep 29, 2010, at 3:12 PM, Bill Wendling wrote: > Chris rewrote the original LLVM bytecode into it's present bitcode form. The newer code is much smaller than the previous form. That would be my guess for why he chose to call it bitcode. Of course, he can say for himself. :-) The format is literally a bitstream, not a bytestream. See this document for more details:

On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > 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

On Oct 10, 2012, at 5:10 PM, Jan Voung <jvoung at chromium.org> wrote: > Thanks for the review Rafael! > > Chris, did you want to take a look at the patch too? Your most recent patch looks good to me, with a minor change: +++ b/lib/Bitcode/Writer/BitcodeWriter.cpp @@ -33,6 +33,13 @@ using namespace llvm; static cl::opt<bool>

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

On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > 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

On Tue, Apr 4, 2017 at 1:25 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 4, 2017, at 12:12 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi,

> On Oct 28, 2016, at 2:16 PM, Will Dietz <willdtz at gmail.com> wrote: > > On Fri, Oct 28, 2016 at 2:06 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: >> On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: >>> >>> On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev

On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: > On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> > >> > >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter

On Wed, Sep 26, 2012 at 2:07 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2012 01:08, Jan Voung <jvoung at chromium.org> wrote: > > - Forward references will create negative-valued ids (which end up being > > written out as large 32-bit integers, as far as I could tell). > > Can you use an SLEB-like representation? > > It's

On Fri, Oct 28, 2016 at 2:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: >> >> On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com>

As I understand it, the bitcode compatibility promise doesn't extend as far as debug info metadata (happy to be wrong here!). I think we have a usecase where need to guarantee that debug information from any two arbitrary bitcode files going into an LTO link will result in the expected/correct debug information going into the resulting ELF file; unless we can be sure that this will always

Hi Matt, thanks for the reply. * Matt Zimmerman (mdz@debian.org) wrote: > On Tue, Oct 30, 2001 at 11:39:11PM -0800, Joshua Haberman wrote: > > > So I was wondering if flac could be incorporated into the filesystem > > driver so that any file ending in .wav would be transparently encoded > > into flac. I don't know if this could be done at the vfs level so that >

On 26 September 2012 22:08, Jan Voung <jvoung at chromium.org> wrote: > I think most of the instructions operands are encoded as VBR(N) > for some N number of bits, and it seems to me that VBR(8) is like ULEB? > I think that the default N is 6 bits, but I haven't tried tweaking these > parameters. It has a similar purpose, but slightly different. SLEB (the signed version)