This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 03/25] Improve TARGET_MANGLE_DECL_ASSEMBLER_NAME.
On Wed, Sep 12, 2018 at 5:07 PM Jeff Law <law@redhat.com> wrote:
>
> On 9/12/18 8:42 AM, Richard Biener wrote:
> > On Wed, Sep 12, 2018 at 12:56 AM Jeff Law <law@redhat.com> wrote:
> >>
> >> On 9/5/18 5:48 AM, ams@codesourcery.com wrote:
> >>>
> >>> The HSA GPU drivers can't cope with binaries that have the same symbol defined
> >>> multiple times, even though the names are not exported. This happens whenever
> >>> there are file-scope static variables with matching names. I believe it's also
> >>> an issue with switch tables.
> >>>
> >>> This is a bug, but outside our control, so we must work around it when multiple
> >>> translation units have the same symbol defined.
> >>>
> >>> Therefore, we've implemented name mangling via
> >>> TARGET_MANGLE_DECL_ASSEMBLER_NAME, but found some places where the middle-end
> >>> assumes that the decl name matches the name in the source.
> >>>
> >>> This patch fixes up those cases by falling back to comparing the unmangled
> >>> name, when a lookup fails.
> >>>
> >>> 2018-09-05 Julian Brown <julian@codesourcery.com>
> >>>
> >>> gcc/
> >>> * cgraphunit.c (handle_alias_pairs): Scan for aliases by DECL_NAME if
> >>> decl assembler name doesn't match.
> >>>
> >>> gcc/c-family/
> >>> * c-pragma.c (maye_apply_pending_pragma_weaks): Scan for aliases with
> >>> DECL_NAME if decl assembler name doesn't match.
> >> This should be fine. But please verify there's no regressions on the
> >> x86_64 linux target, particularly for the multi-versioning tests (mv*.c
> >> mv*.C
> >
> > Err - the patch clearly introduces quadraticness into a path which
> > isn't acceptable.
> > get_for_asmname works through a hashtable.
> But isn't this only being rused when we aren't able to find the symbol?
This case seems to happen though.
> My impression was that should be rare, except for the GCN target.
Still even for the GCN target it looks like a hack given the linear search.
I think it is required to track down the "invalid" uses of DECL_NAME vs.
"mangled" name instead.
> >
> > It also looks like !target can readily happen so I wonder what happens if an
> > assembler name does not match but a DECL_NAME one does by accident?
> >
> > I fear you have to fix this one in a different way... (and I hope
> > Honza agrees with me).
> Honza certainly knows the code better than I. If he thinks there's a
> performance issue and this needs to be resolved a better way, then I'll
> go along with that.
I think the symptom GCN sees needs to be better understood - like wheter
it is generally OK to mangle things arbitrarily.
Note that TARGET_MANGLE_DECL_ASSEMBLER_NAME might not be
a general symbol mangling hook but may be restricted to symbols with
specific visibility.
Richard.
>
> Jeff