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?
