> Hi Honza,
>
> > On 8 Jul 2025, at 2:26 am, Jan Hubicka <hubi...@ucw.cz> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi,
> > as discussed also on the autofdo pull request, LLVM solves the same
> > problem using -funique-internal-linkage-names
> > https://reviews.llvm.org/D73307
> >
> > All non-public functions gets theis symbol renamed from
> > <function_name>.__uniq.<md5 sum of source file name in decadic>
>
> How is __uniq.<md5 sum of source file name in decadic> added to static
> symbols in the profile?
The patch does three things
1) extends ipa-visibility pass to rename all non-public function
symbols adding the __uniq suffix.
This skips those marked as used so asm statements can work.
2) makes dwarf2out to always add DW_AT_linkage_name attribute to
inlined to DW_TAG_inlined_subroutine dies
3) extends auto-profile to accept profiles with unique names
when building without unique names and vice versa.
I think it is pretty much what LLVM does except that I compute hash
based on object file name while LLVM uses filename of the outer
translation unit (which is easy to change, I just wanted to have
something functional to see how it works in practice).
There is a comment on the pull request comment I added
https://github.com/google/autofdo/pull/244#issuecomment-3046121191
So it seems that llvm folks are not that happy with uniq suffixes since
it breaks asm statements in Linux kernel. I originally tought renaming
is done in dwarf only but indeed renaming all static symbols is quite
radical.
Their proposal
https://discourse.llvm.org/t/rfc-keep-globalvalue-guids-stable/84801
seems to be equivalent to what we have as profile_id. It is 64bit
identifier of a function that should be stable across builds and (modulo
conflits) unique within translated program. Currently it is assigned
only to functions that may be used as indirect call targets and is used
by normal FDO for resolving cross-unit indirect calls.
One option would be to use profile IDs in auto-profiles too. I guess
they can be streamed to dwarf via an extension as 64bit IDs. But it is
not clear to me that it is what LLVM folks work on and if it will
eventually get upstreamed.
If we want to finish your solution (adding file names in create_gcov). I
think we need to solve the following:
1) extend dwarf2out to add DW_AT_linkage_name attributes for all
function symbols. This is easy to do.
2) veirfy that create_gcov can safely determine symbols with public
or static linkage (even inlined ones). There is DW_AT_public
attribute
and stream file names only for public linkage symbols
3) instead of streaming filename of file containing the symbol
stream filename of the corresponding translation unit.
I would say that the advantage of profile id is probably shorter gcov
files, advantage of streaming filename:symbol_name pairs is that the
profile info is easier to read. What do you think?
Honza
