https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117010
--- Comment #8 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Well, indeed. Offloading code generation uses the LTO machinery, including the
'lto1' front end, and thus has 'gcc/common.opt:in_lto_p' set to 'true':
; True if this is the lto front end. This is used to disable gimple
; generation and lowering passes that are normally run on the output
; of a front end. These passes must be bypassed for lto since they
; have already been done before the gimple was written.
Variable
bool in_lto_p = false
The "weak", "comdat" transformations are described at the high level in
'gcc/doc/lto.texi':
The whole program mode assumptions are slightly more complex in
C++, where inline functions in headers are put into @emph{COMDAT}
sections. COMDAT function and variables can be defined by
multiple object files and their bodies are unified at link-time
and dynamic link-time. COMDAT functions are changed to local only
when their address is not taken and thus un-sharing them with a
library is not harmful. [...]
If I force-disable 'pass_ipa_whole_program_visibility':
--- gcc/ipa-visibility.cc
+++ gcc/ipa-visibility.cc
@@ -993,4 +993,7 @@ public:
unsigned int execute (function *) final override
{
+#ifdef ACCEL_COMPILER
+ return 0;
+#endif
return whole_program_function_and_variable_visibility ();
}
..., then we get the expected 'diff' for GCN offloading compilation's
'[...].xamdgcn-amdhsa.mkoffload.082i.whole-program' (and similar for nvptx
offloading compilation's '[...].xnvptx-none.mkoffload.082i.whole-program'):
-Marking local functions: __ct_comp /2 __ct_base /1
[...]
@@ -49,22 +40,24 @@
_ZN1VILi0EEC1Ev/2 (__ct_comp )
Type: function definition analyzed alias
- Visibility: semantic_interposition prevailing_def_ironly
+ Visibility: externally_visible semantic_interposition public weak comdat
comdat_group:_ZN1VILi0EEC5Ev one_only
+ Same comdat group as: _ZN1VILi0EEC2Ev/1
References: _ZN1VILi0EEC2Ev/1 (alias)
Referring:
Read from file: pr117010-1_.o
- Availability: local
+ Availability: available
Unit id: 1
- Function flags: local
+ Function flags:
Called by: _Z3foov/3
Calls:
_ZN1VILi0EEC2Ev/1 (__ct_base )
Type: function definition analyzed
- Visibility: semantic_interposition no_reorder prevailing_def_ironly
+ Visibility: externally_visible semantic_interposition no_reorder public
weak comdat comdat_group:_ZN1VILi0EEC5Ev one_only
+ Same comdat group as: _ZN1VILi0EEC1Ev/2
References:
Referring: _ZN1VILi0EEC1Ev/2 (alias)
Read from file: pr117010-1_.o
- Availability: local
+ Availability: available
Unit id: 1
- Function flags: local
+ Function flags:
Called by:
Calls:
..., and we get the expected 'diff' for the GCN offloading code,
'[...].xamdgcn-amdhsa.mkoffload.2.s' (and similar for the nvptx offloading
code, 'pr117010-1_.xnvptx-none.mkoffload.s'):
+ .section
.text._ZN1VILi0EEC2Ev,"axG",@progbits,_ZN1VILi0EEC5Ev,comdat
.align 2
+ .weak _ZN1VILi0EEC2Ev
.type _ZN1VILi0EEC2Ev,@function
[...]
.size _ZN1VILi0EEC2Ev, .-_ZN1VILi0EEC2Ev
+ .weak _ZN1VILi0EEC1Ev
.set _ZN1VILi0EEC1Ev,_ZN1VILi0EEC2Ev
Now, so much for the mechanics. What this means semantically: whether
'in_lto_p' should vs. shouldn't actually be set for offloading compilation,
I/we have to spend more thought on, whether all these
transformations/optimizations guarded by 'in_lto_p' are generally applicable to
offloading compilation or not?
(..., and I also conclude that the bug that gives rise to the problem
originally reported in this PR isn't related to
'pass_ipa_whole_program_visibility' specifically, but may certainly be located
around here.)
