[PATCH] D76336: [DWARF] Emit DW_AT_call_pc for tail calls

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D76336#1930089 <https://reviews.llvm.org/D76336#1930089>, @vsk wrote:

> In D76336#1930066 <https://reviews.llvm.org/D76336#1930066>, @dblaikie wrote:
>
> > In D76336#1929994 <https://reviews.llvm.org/D76336#1929994>, @vsk wrote:
> >
> > > In D76336#1928056 <https://reviews.llvm.org/D76336#1928056>, @dblaikie wrote:
> > >
> > > > (general caveat: this should be committed as separate patches - between llvm and llvm-dsymutil (much like llvm-dwarfdump and llvm codegen are usually committed separately) - but yeah, it's nice to see it all together for review))
> > >
> > >
> > > Sounds good, I'll split this up before committing.
> > >
> > > > Do you happen to have numbers for, say, clang, on the growth of object size because of this - specifically I'd be interested in the growth of the .rela.debug_addr section in a DWARFv5 build.
> > >
> > > I looked at the size impact on a Darwin -gdwarf-4 stage2 clang build. The aggregate size of .o's post-patch grows 0.006% (8367046264 bytes -> 8367544576 bytes, a 486KB increase). Tail calls make up ~5% of all calls (in clang at least), so this is in line with what was measured in D72489 <https://reviews.llvm.org/D72489>. In D72489 <https://reviews.llvm.org/D72489>, I added a relocation to every non-tail call site entry, which increased the aggregate .o size by 0.04% (~3MB).
> > >
> > > I don't think linker support for dwarf5 is mature enough on Darwin for me to measure. Perhaps that measurement wouldn't be very useful, as ELF relocations are different.
> >
> >
> > Right, an ELF measurement is what I was interested in, owing to the different relocations & .rela.debug_addr is especially significant to my use case involving split DWARF and compressed DWARF, so some of the largest remaining content is debug_addr relocations.
>
>
> I'll find a linux system and share some numbers tomorrow.


Thanks!

>> 
>> 
>>>> Did I understand correctly from previous discussions that the goal was to have call_sites for /every/ call, at some point? (I'm concerned that'll be a /lot/ of addresses)
>>> 
>>> Yes. When tuning for lldb, we've been emitting call sites for every call for some time now.
>> 
>> But they haven't had addresses on them?
> 
> They have had addresses, DW_TAG_call_site may contain DW_AT_call_return_pc, which is an address as of D72489 <https://reviews.llvm.org/D72489>.

"may"? or does in all cases? So this review is about changing some of those (specifically the ones on tail calls) call_return_pc to call_pc?

>> Hmm, that doesn't seem to reproduce with a simple example:
>> 
>>   void f1();
>>   void f2() {
>>     f1();
>>   }
>> 
>> 
>> Doesn't have any call_site (compiled with clang with -g -c for linux/x86 or darwin/x86).
> 
> Have you tried adding '-O1 -disable-llvm-passes'? Call site entries aren't emitted unless optimization is enabled.

Ah, right right - thanks for the reminder. (why is this only relevant in optimized builds?) (sorry I keep repeating things with this feature - seems I still don't have it all clearly in my head :/)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76336/new/

https://reviews.llvm.org/D76336