search for: sleb

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 probably not going to be backwards compatible, but if there isn't an SLEB/ULEB representation in bitcode, I'd say it's a good improvement. ;) -- cheers, --renato http://systemcall.org/

...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 probably not going to be backwards compatible, but if there isn't > an SLEB/ULEB representation in bitcode, I'd say it's a good > improvement. ;) > > I think most of the instructions operands are encoded as VBR(N) for some N number of...

...te: > 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) wouldn't use the whole word for -1, since the sign expansion happens after the number is encoded to 7 bits package, so any negative number that can be represented using 7 bits would still be stored in a byte. -- cheers, --renato http://systemcall.org/

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

...hange and not doing anything else, so could have been done more directly with (a) for option (c) it ends up creating a new block ID that overlaps with the existing function one and that would be first one to do that? Thanks again Duncan for the review, and Renato for the suggestion of looking into SLEB. Attached is an updated patch which toggles the change at the module level (done with option a), and uses signed VRBs for phis, - Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121001/72a138aa/attachmen...

..., 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 pro...

...EB to the values, rather than the current char. I could get it to work, but the EmitULEB routines are all moving to Dwarf, including the getULEBSize, which I need to calculate the section size correctly. Is this the only place outside Dwarf that needs ULEB? Does it justify pulling everything ULEB/SLEB related to MCStreamer or reproducing the code for this special case is acceptable? As a rule of thumb I'd say pulling the code to a generic part is the way to go, but I'm not sure on the plans for MC... cheers, --renato

...hing else, so could have been done more directly with (a) > for option (c) it ends up creating a new block ID that overlaps with the > existing function one and that would be first one to do that? > > Thanks again Duncan for the review, and Renato for the suggestion of looking > into SLEB. Attached is an updated patch which toggles the change at the > module level (done with option a), and uses signed VRBs for phis, This is awesome! I tried it by creating a .ll of all of clang. Some sizes: * clang.ll 490M * clang.ll.gz 55M * clang.ll.bz2 37M * clang.ll.xz 27M with t...

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

On Nov 8, 2012, at 7:09 AM, Joe Abbey <jabbey at arxan.com> wrote: >>> The problem we face is that bitcode changes, and when it does… future versions >>> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn >>> can BitcodeReader from LLVM 3.1, but LLVM 3.1 can't BitcodeReader LLVM 3.2 >>> (after r165739.) There was an

On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Joe, > >> We have a tool which reads in bitcode, processes it, and re-emits it. We use >> this tool as a flexible way to integrate our tool into the Xcode, Android NDK, >> Chromium, and Linux build process. >> >> The problem we face is that bitcode changes, and when it does…