[Bug c++/105625] New: Support .llvm_addrsig section

[Bug c++/105625] New: Support .llvm_addrsig section

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

            Bug ID: 105625
           Summary: Support .llvm_addrsig section
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rui314 at gmail dot com
  Target Milestone: ---

This is a feature request to implement an LLVM-compatible feature so that
linkers can optimize GCC-generated object files as much as they can currently
do for LLVM-generated ones.

Disclaimer: I'm the creator of the mold linker (https://github.com/rui314/mold)

Background:

GNU gold and LLVM lld have a feature so-called Identical Code Folding (ICF).
ICF finds functions that happen to be compiled to the exact same machine code
to merge them. This is known as an effective optimization especially for C++
programs, since a function template tend to be compiled to the same machine
code for different types. For example, `std::vector<int>` and
`std::vector<unsigned>` are likely to be instantiated to the exact same machine
code, even though they will get different mangled names. ICF can merge such
code.

There's one caveat though. ICF is not a "safe" optimization. In C/C++, two
function pointers are equal if and only if they are pointing the same function.
For example, if you have two different functions `foo` and `bar`, `foo == bar`
will never be true. ICF breaks this assumption if it merges `foo` and `bar`, as
after merging, they will be at the same address.

That said, if you know that there's no code that takes a pointer of `foo` or
`bar`, it is safe to merge `foo` with `bar`, since it's impossible to compare
pointers without taking their addresses. gold and lld implement a "safe" ICF
with that observation.

The gold's safe ICF merges only C++ constructors and destructors. Since there's
no way to obtain a pointer of a ctors or dtors within the C++ language spec,
they are always safe to merge. gold identifies ctors and dtors by reading their
mangled names. What gold does is safe but too conservative as it cannot merge
other functions.

The lld's safe ICF works with an LLVM feature. Since mid-2018, LLVM emits a
`.llvm_addrsig` section to all object files by default. That section contains
symbol indices whose addresses are taken. Using this table, lld can merge
functions more aggressively than gold can do.

Recently, we implemented an lld-compatible safe ICF to mold. It works great,
but it doesn't work with GCC as GCC does not produce `.llvm_addrsig` sections.

Feature request:

Can GCC produce the `.llvm_addrsig` section just like LLVM does? It will make
GCC-generated executables on par with LLVM-generated ones with ICF in terms of
file size.

References:

Here is an explanation of the `.llvm_addrsig` section:
https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table

This is a patch to have added the feature to LLVM:
https://reviews.llvm.org/D47744

Here is an upstream issue for mold: https://github.com/rui314/mold/issues/484

[Bug c++/105625] Support .llvm_addrsig section

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I see most of it was implemented in the assembler. So you might want to report
the support for .addrsig directive there too.

[Bug c++/105625] Support .llvm_addrsig section

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2022-05-17
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>From reading the specifications of the extension, you do need assembler support
first as there is no way for GCC to emit a reference to the index of the symbol
table as that is not exposed via normal assembler directives.

Suspended until GNU binutils support is added.

[Bug ipa/105625] Support .llvm_addrsig section

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

--- Comment #3 from Rui Ueyama <rui314 at gmail dot com> ---
I think we can implement the `.addrsig` support to the assembler, but I wonder
if GCC will support it once the GNU assembler gains the feature?

[Bug ipa/105625] Support .llvm_addrsig section

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rui Ueyama from comment #3)
> I think we can implement the `.addrsig` support to the assembler, but I
> wonder if GCC will support it once the GNU assembler gains the feature?

Yes I think it will, shouldn't be too hard to implement because IPA cgraph
already has that information and uses it for ICF inside GCC.

[Bug ipa/105625] Support .llvm_addrsig section

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

--- Comment #5 from Rui Ueyama <rui314 at gmail dot com> ---
Cool! We'll add a `.llvm_addrsig` support to binutils and get back to you guys.

[Bug ipa/105625] Support .llvm_addrsig section

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
Good, I can prepare a GCC patch once the binutils support is there.

[Bug ipa/105625] Support .llvm_addrsig section

[ishitatsuyuki at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625

--- Comment #7 from Tatsuyuki Ishi <ishitatsuyuki at gmail dot com> ---
https://sourceware.org/pipermail/binutils/2022-May/121000.html

I just posted an initial revision of the patchset for gas.