search for: uleb

Hi all, I'm playing ARMAsmPrinter and there is a FIXME in ObjectAttributeEmitter which should print a ULEB 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/SL...

...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/

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

...ention the idea. I agree it's not worth pursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs that had DW_AT_linkage_name without DW_AT_name; it...

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) wouldn't use the whole word for -1, since the sign expansion happens after the number is encoded to 7 bits package, so...

...relocations (& reducing .o file size with Split DWARF) by allowing many uses of addresses to include some kind of address+offset (debug_rnglists and loclists allowing "base_address" then offset_pairs (an improvement over similar functionality in DWARFv4 because the offset pairs can be uleb encoded - so they can be quite compact)) But one place that DWARFv5 misses to reduce relocations further is direct addresses from debug_info, such as DW_AT_low_pc. For a while I've wondered if we could use an extension form for addr+offset, and I prototyped this without an extension attribute...

...educing .o file size with Split > DWARF) by allowing many uses of addresses to include some kind of > address+offset (debug_rnglists and loclists allowing "base_address" then > offset_pairs (an improvement over similar functionality in DWARFv4 because > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > But one place that DWARFv5 misses to reduce relocations further is > direct addresses from debug_info, such as DW_AT_low_pc. > > > > For a while I've wondered if we could use an extension form for > addr+offset, and...

> To summarize my understanding: Neither of these operators is strictly necessary, since the same effect can be achieved by implicitly pushing all operands of a DBG_VALUE to the stack, followed by a combination of DW_OP_dup, DW_OP_pick, DW_OP_swap, DW_OP_rot, and DW_OP_over. However, the resulting expressions can get very long and unwieldy and it is easier to generate efficient DWARF from

...think it is possible to separate the in-memory encoding from the visual representation. There is no reason why we couldn't encode DW_OP_LLVM_arg N in one 64-bit integer field. The DIExpression iterator can hide this detail. More generally, we could encode *all* fields in DIExpressions as, e.g, ULEB values in memory and hide that behind the iterator. With that perspective I think DW_OP_LLVM_arg N is the way to go, and if we are really bothered by the storage size, we can address this separately. > > thanks, > adrian > > > > >> Finally, to completely derail this discu...

...with Split > > DWARF) by allowing many uses of addresses to include some kind of > > address+offset (debug_rnglists and loclists allowing "base_address" then > > offset_pairs (an improvement over similar functionality in DWARFv4 because > > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > > > But one place that DWARFv5 misses to reduce relocations further is > > direct addresses from debug_info, such as DW_AT_low_pc. > > > > > > For a while I've wondered if we could use an extension form f...

...think it is possible to separate the in-memory encoding from the visual representation. There is no reason why we couldn't encode DW_OP_LLVM_arg N in one 64-bit integer field. The DIExpression iterator can hide this detail. More generally, we could encode *all* fields in DIExpressions as, e.g, ULEB values in memory and hide that behind the iterator. With that perspective I think DW_OP_LLVM_arg N is the way to go, and if we are really bothered by the storage size, we can address this separately. > >> > >> thanks, > >> adrian > >> > >>> > >&...

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

...wing many uses of addresses to include some kind of >>>> > address+offset (debug_rnglists and loclists allowing "base_address" then >>>> > offset_pairs (an improvement over similar functionality in DWARFv4 because >>>> > the offset pairs can be uleb encoded - so they can be quite compact)) >>>> > > >>>> > > But one place that DWARFv5 misses to reduce relocations further is >>>> > direct addresses from debug_info, such as DW_AT_low_pc. >>>> > > >>>> > > For a...

...is a lot involved in this, to say the least, but this is important for "llvm-mc as a disassembler API". 6. Implement the "assembler middle end", which handles relaxation operations (e.g. determining whether something is a short or long branch on x86, figuring out how big a uleb has to be, etc), which generates the final fragments (which are basically going to be llvm::BinaryObject's). 7. Implement support for writing a .o file. As you can see, llvm-mc is a pretty ambitious and non-trivial project. Because of this, I don't expect to get to #7 for a couple...

Hi all, I've been waiting for almost three months now to get a patch committed to LLVM that fixes what I consider to be a fairly significant bug in the JIT (http://llvm.org/bugs/show_bug.cgi?id=13678) but I've been having a hard time getting traction on it. So far Duncan Sands is the only one who has given it any attention, but as of the last time I checked it still wasn't committed

On Fri, Nov 18, 2016 at 10:18 AM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Nov 18, 2016 at 8:43 AM Greg Clayton <gclayton at apple.com> wrote: > > > > On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----Original Message----- > >> From: Greg Clayton