similar to: [LLVMdev] [PATCH] More BitCodeFormat.html improvements

Hi Jan, > 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 improvement is wonderful! ... > In any case, the patch is attached if

I think it just changed formats which prompted a change in ID -- the code now uses TYPE_BLOCK_ID_NEW (= 17). I haven’t looked deeply to see how different it is. Ismail > On Oct 13, 2016, at 2:02 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Oct 13, 2016, at 10:24 AM, Ismail Badawi (ibadawi) via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

Hi folks, A while back I noticed some outdated information in docs/BitCodeFormat.rst about how parameter attributes were encoded — it describes an old encoding that was changed in 3.3 with the introduction of attribute groups. I opened a bug about this (https://llvm.org/bugs/show_bug.cgi?id=28941) and started trying to write a patch, but along the way ran into more and more issues (e.g. new

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:

Peter Zotov писал 09.01.2013 19:59: > Hello. > > I've managed to create a bitcode file (attached; also available at > [1]) which produces > a series of identical errors when verified: > > | Global variable initializer type does not match global variable > type! > | %i.NilClass* @nil > > When ran through llvm-dis and recompiled, through, it verifies >

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

The enclosed patch contains a number of wording and clarity improvements to BitCodeFormat.html, and documents in detail the record types used within MODULE blocks. I plan to continue documenting the rest of the record types, but I wanted to submit patches in reasonably-sized pieces. -Peter S. Housel- housel at acm.org -------------- next part -------------- A non-text attachment was scrubbed...

Hello. I've managed to create a bitcode file (attached; also available at [1]) which produces a series of identical errors when verified: | Global variable initializer type does not match global variable type! | %i.NilClass* @nil When ran through llvm-dis and recompiled, through, it verifies successfully. If I disassemble it one more time, the result is identical to the first

Chad, Yes it helps, thanks. I have started hacking bitcode-analyzer. ---ajonwa ----- Original Message ----- From: Chad Rosier Sent: 11/05/11 09:07 PM To: ajonwa ajonwa Subject: Re: [LLVMdev] Enable Detailed Output llvm-bcanalyzer ajonwa, It will provide some of the information you're seeking, but not all. Here's a partial dump from one of the bitcode test cases:

As discussed in the high-level ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), we would like to add support for native object wrapped bitcode and ThinLTO information. Based on comments on the mailing list, I am adding support for ThinLTO in both normal bitcode files, as well as native-object wrapped bitcode. The following RFC describes the planned file format of

Hi Alex, After outlining some of the rationale for using native-wrapped, there were a couple of responses that indicated native-wrapped support was reasonable, but they preferred to see bitcode-only first (Phillip and Rafael). This is essentially what this proposal and the patches do - I've implemented some of the basic support for looking for and parsing the native-wrapped sections, but the

Hi all, I updated the patches to remove the native object wrapper format. As suggested we will work on getting the ThinLTO framework in place using bitcode first, and then work on adding the native object support. As noted in this RFC and in the associated patch D11722, for now I have empty ThinLTO blocks with no records, since I wanted to get feedback on the overall block design first. The RFC

This fixes a regression introduced by 9e3d1160. Snapshot was leaving both dev and file attributes specified. The result was that the v2v would actually operate on the underlying storage rather than the snapshot. --- snapshot/v2v-snapshot.pl | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/snapshot/v2v-snapshot.pl b/snapshot/v2v-snapshot.pl index f089a77..e2cc33c 100755

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:

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

> > 3.) Then I used clang-cl to generate a .bc file - but now I'm not able to > use "llvm-readobj" anymore. Is there any tool available which can dump this > debug information too? > ​.bc is LLVM bitcode [1], not the usual object file. `llvm-readobj` should works only on the latter. ​[1] https://llvm.org/docs/BitCodeFormat.html -- Wei-Ren Chen (陳韋任) Homepage:

Am 30.09.2010 00:34, schrieb Chris Lattner: > > The format is literally a bitstream, not a bytestream. See this document for more details: > http://llvm.org/docs/BitCodeFormat.html Ah... something I always meant to ask: How does the LLVM infrastructure deal with the added overhead of packing/unpacking a bitstream? Ignore it since modern CPUs can deal with that? Some ingenious

> Anton, would it be possible to add information to the documentation > here: > http://llvm.org/docs/BitCodeFormat.html Sure! Any further comments? Many thanks, Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: half-doc.patch Type: application/octet-stream Size: 657 bytes Desc: not available URL:

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>

Anton, would it be possible to add information to the documentation here: http://llvm.org/docs/BitCodeFormat.html > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Villmow, Micah > Sent: Thursday, May 17, 2012 9:04 AM > To: Anton.Lokhmotov at arm.com; 'David Neto' > Cc: llvmdev at cs.uiuc.edu >