[Bug ipa/97119] New: Top level option to disable creation of IPA symbols such as .localalias is desired

[Bug ipa/97119] New: Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com]

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

            Bug ID: 97119
           Summary: Top level option to disable creation of IPA symbols
                    such as .localalias is desired
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ali_gccbugzilla at emvision dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I work on the Solaris linkers, and in that role, often
collaborate with Rainer Orth to keep gcc working on that
platform. As part of that, we use gcc to build the OS along
with the native Studio compilers, as a means to better test
things, and because we often find that one compiler finds issues
that the other doesn't.

A couple of years ago (gcc 5?), we became aware of symbols ending
in .localalias.nn, .part.nn, and isra.dd. While this is very
impressive technology, particularly when C++ templates are generating
reams of identical code bodies for various interfaces, it poses
some problems for using gcc to build the core Solaris OS.

To understand the issue, it is necessary to understand that
Solaris has a large infrastructure dedicated to producing
accurate stack traces purely from examining in memory
object content (symbol tables, etc) and not relying on
access to the on-disk image, or on any debug sections.
Our libproc does this efficiently, and as part of that, relies
on symbol sort sections generated by the linkers to map symbol
names to addresses, or addresses to names. When mapping addresses
to names, it is important that the name we report be the one that
the programmer would understand, and not some other name that
happens to have the same address, due to some under the hood
optimizations. DTrace, mdb, and the ptools (pstack, etc) all
rely on this.

In this context, the local symbols generated by IPA, and particularly
the .localalias symbols, mess up our results, causing our 
address-to-name tables to have multiple names, some of which are
optimization implementation details that are not what the
programmer would want to see. Even worse is the case where
2 functions have their bodies merged into one piece of text
with 2 different names. Showing the user the "wrong" name for
a function on their stack can be very misleading, and can cause
wasted debugging time until they realize that they're seeing an
IPA artifact. At the same time, the core OS is largely written in
C, so the benefits from these particular IPA features are modest
at best. We have found a few merged function bodies, and in this
case, the minor duplication bloat is a price worth paying to get
the correct name associated to the different instances.

With previous versions of gcc, we were able to disable the
production of these symbols by using -fno-ipa-icf, so we did
that and moved on. With gcc10 however, we find that -fno-ipa-icf
is not sufficient, and that we still see .localalias symbols
in the resulting links. Although I'm sure that there is another
option like -fno-ipa-icf that we could set to address
that, I would like to ask for a supported way to turn off all
IPA that causes symbols like these to be injected into the link.
so that we can opt out for our admittedly specialized purposes,
and without having to revisit it every time a new gcc version appears,
or dig into the underlying optimization passes to figure out what
to turn off.

Please note that turning down optimization (e.g. -g) in order to
achieve this isn't the sort of answer we're looking for. These are
not debug objects, but rather objects built for production use. Hence
 we want to retain optimizations that don't generate extra symbols
in a simple and maintainable way.

Rainer did a one off experiment that showed that it would be
fairly easy to provide this. I'll leave it to him to describe.

Thanks for your consideration of this.

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-09-21

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
You likely want to disable all IPA optimizations that create clones.
Probably the same what -flive-patching=inline-only-static does? Please see a
man page for the -flive-patching option.

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 49246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49246&action=edit
Hack to disable .localalias* generation

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Ali Bahrami from comment #0)

> Rainer did a one off experiment that showed that it would be
> fairly easy to provide this. I'll leave it to him to describe.

Right: initially I looked around trying to find a set of options to turn off
generation of those .localalias* symbols, but was unable to find any.

In an experiment to assess any testsuite impact of disabling their generation,
I came up with the attached hack.  It passed sparc-sun-solaris-2.11 testing
without regressions, while on amd64-pc-solaris2.11 there was a single
regression:

+FAIL: gcc.dg/pr56727-1.c scan-assembler-not @(PLT|plt)

(32-bit only).

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is no way to turn all of these, and I'm afraid can't be.
E.g. for the OpenMP/OpenACC outlined bodies of constructs, they need to be
named somehow.
Sure, one can disable many other ways how to clone functions (e.g. effectively
imply all functions have noclone attribute), but it will not handle everything.

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com]

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

--- Comment #5 from Ali Bahrami <ali_gccbugzilla at emvision dot com> ---
I added -flive-patching=inline-only-static as suggested by Martin. It didn't
alter the results I'm seeing. There is still a lot of .localalias in the
resulting objects. Still, the optimizations it is documented as preventing all
seem like the sort of things we wouldn't want for the core OS objects, so we
probably should add this.

I'm at a disadvantage here, as I don't fully understand how clone functions and
.localalias symbols are related. From the gcc manpage, I gather that clones are
copies made to do certain optimizations, such as elimination of constant
arguments. In contrast, foo, and foo.localalias seen to be references to a
single function, with the main different being that foo is global and
foo.localias is local. I'm not sure what the benefit of the local symbol is,
but since it references the same address, as the global, it's not what I would
call a clone.

In any event, I would be content with a way to disable these for
straightforward C objects, as opposed to specialized cases like OpenMP/OpenACC,
so perhaps there's a way to do that, even if the fully general case isn't
possible?

Thanks.

- Ali

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #5 from Ali Bahrami <ali_gccbugzilla at emvision dot com> ---
> I added -flive-patching=inline-only-static as suggested by Martin. It didn't
> alter the results I'm seeing. There is still a lot of .localalias in the
> resulting objects. Still, the optimizations it is documented as preventing all
> seem like the sort of things we wouldn't want for the core OS objects, so we
> probably should add this.

I've since compared the list of options disabled by
-flive-patching=inline-only-static with the call sites of
noninterposable_alias and the options that controlled their use.  I'd
initially done this to come up with additional options to try on top of
-fno-ipa-icf that Ali had been using.

This identified two more to try:

    -fdevirtualize
    -fipa-profile

However, Ali found that disabling those doesn't help either.

Any additional suggestions what else to try here?

> I'm at a disadvantage here, as I don't fully understand how clone functions and
> .localalias symbols are related. From the gcc manpage, I gather that clones are
> copies made to do certain optimizations, such as elimination of constant
> arguments. In contrast, foo, and foo.localalias seen to be references to a
> single function, with the main different being that foo is global and
> foo.localias is local. I'm not sure what the benefit of the local symbol is,
> but since it references the same address, as the global, it's not what I would
> call a clone.

This is still an important issue, I believe: without fully understanding
what those symbols are needed for and what the consequences would be of
disabling their creation, it's hard to decide what to do.

Going back to my initial hack (attached) of disabling .localalias*
creation, what it does is exactly what happens on targets that don't
define ASM_OUTPUT_DEF, i.e. don't support aliases.  At least a testsuite
run identified almost no impact (one failing test on Solaris/x86).
Given that this is a supported configuration, I'd expect that this
doesn't result in wrong code.

Would a patch along those lines (properly controlled by an
off-by-default option) be acceptable to move this forward?

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Local aliases are created by ipa-visibility pass.  Most common case is that
function is declared inline but ELF superposition rules say that the symbol can
be overwritten by a different library.  Since GCC knows that all
implementaitons must be equivalent, it can force calls within DSO to be direct.

I am not quite sure how this confuses stack unwinding on Solaris?

For live patching, if you want to patch inline function, one definitely needs
to look for places it has been inlined to. However in the situation the
function got offlined, I think live patching should just work, since it will
place jump in the beggining of function body.

The logic for creating local aliases is in ipa-visibility.cc.  Adding command
line option to control it is not hard. There are other transformations we do
there - like breaking up comdat groups and other things.

part aliases are controlled by -fno-partial-inlining, isra by -fno-ipa-sra.
There is also ipa-cp controlled by -fno-ipa-prop.
We also do alises as part of openMP offlining and LTO partitioning that are
kind of mandatory (there is no way to produce correct code without them).

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com]

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

--- Comment #8 from Ali Bahrami <ali_gccbugzilla at emvision dot com> ---
> I am not quite sure how this confuses stack unwinding on Solaris?

I don't think that most of what you described is a problem
for stack unwinding on Solaris. As discussed in the initial
note, the problem is that we use a table that maps address to
function names ("sort sections") to map virtual addresses to
symbols, and then use those symbol names for the stack
trace. The localalias, and similar, symbols that gcc is
producing make trouble for us, in a couple of ways:

    (1) Since these symbols have the same addresses as the
        original functions, they might show up in the stack
        trace output, rather than the "real" name that the
        programmer used.

    (2) In the case where gcc replaces multiple identical
        function bodies with one instance, the original 1:1
        relationship between name and address is lost. Imagine
        that my code has functions fooA() and fooB() that get
        collapsed into one body, and now, both functions have
        the same address. My stack traces may show one when the
        programmer actually called the other.

(1) is just an annoyance. (2) is a bit more serious, since
conceptually, fooA() and fooB() really are different, and the
programmer really should see a stack that reflects what their
source code says.

As to why this is done, it's a way to get a useful
stack trace for code that has no debug sections, or
in contexts where running a debugger to get a trace
isn't possible. We put a high priority on observabilty
in contexts where debug sections are not available, or
running a debugger is not possible.

As I hope was clear in my original note, we think these gcc
optimizations are very useful for lots (maybe most) code,
but for our very simple C code base, the win is small, and
the negative aspects are a problem. It would be very useful
for us if this class of optimization could be disabled with
a simple switch.

We filed this request almost 4 years ago, and seeing that it
wasn't getting traction, I've since modified our link-editor
to drop all symbols of the form

    XXX.isra.dd
    XXX.localalias.dd
    XXX.part.dd

from the sort sections. It's an effective hack against
problem (1) above, though not (2). It's also not how
linking ought to work: hardwiring and checking the names
of symbols produced by a specific compiler as a side effect
of optimization settings is ugly and error prone. I'd love
to rip it out if we can get back to gcc producing the 1:1
symbol to code address relationship.

Let me know if more explanation is needed. Thanks.

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=63572

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the issue described here are all covered by pr 63572

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com]

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

--- Comment #10 from Ali Bahrami <ali_gccbugzilla at emvision dot com> ---
> I think the issue described here are all covered by pr 63572

Can you explain how? I might not have followed it, but
pr 63572 seems to revolve around generating correct DWARF
content? Here, we're not reading the DWARF at all, so its
correctness isn't a factor. We're not really making any claims
about gcc correctness.

The problem here is that what these optimizations do
cause us difficulties in our simple mapping of addresses
to names, while the optimizations themselves don't have
enough impact to fight for. Hence, we'd like the option
to opt out.

- Ali