Fangrui Song 12050a3fb7 [LTO] Make local linkage GlobalValue in non-prevailing COMDAT available_externally
For a local linkage GlobalObject in a non-prevailing COMDAT, it remains defined while its
leader has been made available_externally. This violates the COMDAT rule that
its members must be retained or discarded as a unit.

To fix this, update the regular LTO change D34803 to track local linkage
GlobalValues, and port the code to ThinLTO (GlobalAliases are not handled.)

This fixes two problems.

(a) `__cxx_global_var_init` in a non-prevailing COMDAT group used to
linger around (unreferenced, hence benign), and is now correctly discarded.
```
int foo();
inline int v = foo();
```

(b) Fix https://github.com/llvm/llvm-project/issues/58215:
as a size optimization, we place private `__profd_` in a COMDAT with a
`__profc_` key. When FuncImport.cpp makes `__profc_` available_externally due to
a non-prevailing COMDAT, `__profd_` incorrectly remains private. This change
makes the `__profd_` available_externally.

```
cat > c.h <<'eof'
extern void bar();
inline __attribute__((noinline)) void foo() {}
eof
cat > m1.cc <<'eof'
#include "c.h"
int main() {
  bar();
  foo();
}
eof
cat > m2.cc <<'eof'
#include "c.h"
__attribute__((noinline)) void bar() {
  foo();
}
eof

clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw

clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto=thin -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw
```

If a GlobalAlias references a GlobalValue which is just changed to
available_externally, change the GlobalAlias as well (e.g. C5/D5 comdats due to
cc1 -mconstructor-aliases). The GlobalAlias may be referenced by other
available_externally functions, so it cannot easily be removed.

Depends on D137441: we use available_externally to mark a GlobalAlias in a
non-prevailing COMDAT, similar to how we handle GlobalVariable/Function.
GlobalAlias may refer to a ConstantExpr, not changing GlobalAlias to
GlobalVariable gives flexibility for future extensions (the use case is niche.
For simplicity we don't handle it yet). In addition, available_externally
GlobalAlias is the most straightforward implementation and retains the aliasee
information to help optimizers.

See windows-vftable.ll: Windows vftable uses an alias pointing to a
private constant where the alias is the COMDAT leader. The COMDAT use case
is skeptical and ThinLTO does not discard the alias in the non-prevailing COMDAT.
This patch retains the behavior.

See new tests ctor-dtor-alias2.ll: depending on whether the complete object
destructor emitted, when ctor/dtor aliases are used, we may see D0/D2 COMDATs in
one TU and D0/D1/D2 in a D5 COMDAT in another TU.
Allow such a mix-and-match with `if (GO->getComdat()->getName() == GO->getName()) NonPrevailingComdats.insert(GO->getComdat());`

GlobalAlias handling in ThinLTO is still weird, but this patch should hopefully
improve the situation for at least all cases I can think of.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D135427
2022-11-16 22:13:22 -08:00
..
2021-02-08 08:55:29 -08:00
2021-02-08 08:55:29 -08:00
2021-02-08 08:55:29 -08:00
2021-02-08 08:55:29 -08:00
2021-02-08 08:55:29 -08:00
2020-06-01 10:19:41 -07:00
2021-10-31 12:10:43 -07:00
2020-03-27 11:56:02 -07:00
2022-08-15 18:49:02 -04:00
2021-01-22 19:07:02 -08:00
2021-10-04 11:10:10 +01:00
2021-10-04 11:10:10 +01:00
2021-10-04 11:10:10 +01:00
2021-10-04 11:10:10 +01:00
2020-08-07 22:08:44 -07:00
2021-02-05 09:37:37 -08:00
2022-08-02 09:52:31 -04:00
2020-06-01 10:19:41 -07:00
2022-01-15 22:33:51 -08:00
2022-01-15 22:33:51 -08:00
2022-10-24 10:54:09 -07:00
2022-01-29 14:45:58 -08:00
2021-10-31 12:10:43 -07:00
2022-07-07 10:16:09 -07:00
2022-06-26 17:26:44 -07:00
2022-09-12 12:56:35 -07:00
2022-09-20 17:12:44 -07:00
2022-10-24 10:54:09 -07:00
2021-10-31 12:10:43 -07:00