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

[Vedant Kumar via Phabricator via llvm-commits]

vsk added a comment.

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.

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

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

>> Hm :(. Digging through the history, I see that I accidentally turned on DIFlagAllCallsDescribed when targeting -gdwarf-4 + GDB in D69743 <https://reviews.llvm.org/D69743> (November 2019). This was done prematurely, I apologize for this. It should not have happened until the entry values feature got enabled by default. I've checked in test coverage for -gdwarf-4 + -ggdb to clang/test/CodeGenCXX/dbg-info-all-calls-described.cpp in 47622efc <https://reviews.llvm.org/rG47622efc6f01532ef1c23490f516efb9081827f8>.
>> 
>> @dblaikie @djtodoro I'd prefer to leave things as they are, but am also open to disabling DIFlagAllCallsDescribed for -gdwarf-4 + -ggdb until entry values get re-enabled by default, let me know what you think.
> 
> Sure, happy to leave things as-is.


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

https://reviews.llvm.org/D76336