<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr">I think I get it now, thanks for explaining!</div><div dir="ltr"><br><blockquote type="cite">On Jan 12, 2020, at 11:44 AM, David Blaikie via llvm-dev <llvm-dev@lists.llvm.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 12:57 PM Vedant Kumar <<a href="mailto:vedant_kumar@apple.com">vedant_kumar@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">I don't totally follow the proposed encoding change & would appreciate a small example.<div><br></div><div>Is the idea to replace e.g. an 'AT_low_pc (<direct address>) + relocation for <direct address>' with an 'AT_low_pc (<indirection into a pool of addresses> + offset)', </div></div></blockquote><div><br>With Split DWARF or with DWARFv5 in LLVM at the moment, all addresses are indirected already. So it's:<br><br>Replace "AT_low_pc (<indirection into a pool of addresses>)" with an "AT_low_pc (<indirection into a pool of addresses> + offset)".<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>s.t. the cost of a relocation for the address is paid down the more it's used? </div></div></blockquote><div><br>Right - specifically to reduce the pool of addresses down to, ideally, one address per section/indivisible chunk of machine code (per subsection in MachO, for instance) (whereas currently there are many addresses per section)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>How do you figure the offset out?</div></div></blockquote><div><br>Label difference - same as is done for DW_AT_high_pc today in DWARFv4 and DWARFv5 in LLVM. high_pc currently uses the low_pc addresse to be relative to, in this proposed situation, we'd use a symbol that's in the first bit of debug info in the section (or subsection in MachO). So the low_pc of the subprogram/function, for instance, or if there are two functions in the same section with debug info for both, the low_pc of the first of those functions, etc... <br></div></div></div></div></blockquote><div dir="ltr"><br></div><div dir="ltr">If the label difference in a low_pc attribute is relative to the start of a section, could a linker orderfile pass break the dwarf unless it updates the offset? Ditto, I suppose, for an intra-function offset when something like propeller is used to reorder basic blocks (I’m thinking of At_call_return_pc now).</div><div dir="ltr"><br></div><div dir="ltr">Apologies if this has been answered elsewhere, I suppose there must be a solution for this for At_high_pc to work.</div><div dir="ltr"><br></div><div dir="ltr">vedant</div><div dir="ltr"><br></div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>thanks,</div><div>vedant<br><div><br><blockquote type="cite"><div>On Jan 8, 2020, at 1:33 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">Sounds good all round - I'll commit these two modes, and maybe even the third (given Sony's interest & possible interest in changing their consumer to handle it) of a custom form to eek out the last few bytes from the more direct addr+offset encoding.<br><br>I'll follow up here with flag names and revision numbers once they're in.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 1:26 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On some previous occasion that introduced additional indirection<br>
(don't remember the details) my debugger people groused about the<br>
additional performance cost of chasing down data in a different <br>
object-file section. So we (Sony) might be happier with low_pc as<br>
expressions, than with a ranges-always solution.<br>
<br>
But hard to say without data, and getting both modes in at least<br>
as a temporary thing sounds like a good plan.<br>
--paulr<br>
<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a> <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>><br>
> Sent: Wednesday, January 8, 2020 1:49 PM<br>
> To: David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Jonas Devlieghere<br>
> <<a href="mailto:jdevlieghere@apple.com" target="_blank">jdevlieghere@apple.com</a>>; Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>>; Eric<br>
> Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>>; Frederic Riss <<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>><br>
> Subject: Re: Increasing address pool reuse/reducing .o file size in<br>
> DWARFv5<br>
> <br>
> I think this sounds like a good plan for Linux. I would like to see the<br>
> numbers for Darwin (= non-split DWARF) to decide whether we should just<br>
> make that the default. Eric's suggestion of having this committed as an<br>
> option first seems like a good step in that direction. If it is an<br>
> advantage across the board we can remove the option and just make this the<br>
> default behavior.<br>
> <br>
> thanks,<br>
> adrian<br>
> <br>
> > On Dec 30, 2019, at 12:08 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> ><br>
> > tl;dr: in DWARFv5, using DW_AT_ranges even when the range is contiguous<br>
> reduces linked, uncompressed debug_addr size for optimized builds by 93%<br>
> and reduces total .o file size (with compression and split) by 15%. It<br>
> does grow .dwo file size a bit - DWARFv5, no compression, not split shows<br>
> the net effect if all bytes are equal: -O3 clang binary grows by 0.4%, -O0<br>
> clang binary shrinks by 0.1%<br>
> > Should we enable this strategy by default for DWARFv5, for DWARFv5+Split<br>
> DWARF, or not by default at all/only under a flag?<br>
> ><br>
> ><br>
> ><br>
> > So, I've brought this up a few times before - that DWARFv5 does a pretty<br>
> good job of reducing relocations (& reducing .o file size with Split<br>
> DWARF) by allowing many uses of addresses to include some kind of<br>
> address+offset (debug_rnglists and loclists allowing "base_address" then<br>
> offset_pairs (an improvement over similar functionality in DWARFv4 because<br>
> the offset pairs can be uleb encoded - so they can be quite compact))<br>
> ><br>
> > But one place that DWARFv5 misses to reduce relocations further is<br>
> direct addresses from debug_info, such as DW_AT_low_pc.<br>
> ><br>
> > For a while I've wondered if we could use an extension form for<br>
> addr+offset, and I prototyped this without an extension attribute, but<br>
> instead using exprloc. This has slightly higher overhead to express the...<br>
> expression. (it's 9 bytes in total, could be as few as 5 with a custom<br>
> form)<br>
> ><br>
> > But I had another idea that's more instantly deployable: Why not use<br>
> DW_AT_ranges even when the range is contiguous? That way the low_pc that<br>
> previously couldn't use an existing address pool entry + offset, could use<br>
> the rnglist support for base address.<br>
> ><br>
> > The only unnecessary address pool entries that remain that I've found<br>
> are DW_AT_low_pc for DW_TAG_labels - but there's only a handful of those<br>
> in most code. So the "ranges everywhere" strategy gets the addresses for<br>
> optimized clang down from 4758 (v4 address pool used 9923 addresses... )<br>
> to 342, with about ~4 "extra" addresses for DW_TAG_labels.<br>
> ><br>
> > This could also be a bit less costly if DWARFv5 rnglists didn't use a<br>
> separate offset table (instead encoding the offsets directly in<br>
> debug_info, rather than using indexes)<br>
> ><br>
> > I have patches for both the addr+offset exprloc and for the ranges-<br>
> always, both with -mllvm flags - do people think they're both worth<br>
> committing for experimentation? Neither? Default on in some cases (like<br>
> Split DWARF)?<br>
> ><br>
> > Thanks,<br>
> > - Dave<br>
<br>
</blockquote></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></div></blockquote></div></div>
<span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span>llvm-dev@lists.llvm.org</span><br><span>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span><br></div></blockquote></div></body></html>