This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, CHKP] Restore transparent alias chains
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 6 Apr 2015 14:56:24 +0300
- Subject: Re: [PATCH, CHKP] Restore transparent alias chains
- Authentication-results: sourceware.org; auth=none
- References: <20150320082033 dot GG64546 at msticlxl57 dot ims dot intel dot com> <551D8B66 dot 90601 at redhat dot com> <20150402184804 dot GE21276 at atrey dot karlin dot mff dot cuni dot cz> <CAMbmDYZththa8_DMVurLzcCzggaCJCwgz3oZrVuahEoUXYVddg at mail dot gmail dot com> <20150403170912 dot GP21276 at atrey dot karlin dot mff dot cuni dot cz>
2015-04-03 20:09 GMT+03:00 Jan Hubicka <hubicka@ucw.cz>:
>>
>> That is the reason for fixing chains in privatize_symbol_name.
>
> OK, so with your proposed patch you produce the links during lto-stream-in
> but because the links may be wrong due to multiple different symbol sharing same
> assembler name you rely on not using it until you fixup in privatize_symbol_name.
> What happen when you have two symbols with different links sharing assembler name
> originally, but you rename one and do not rename other during privatization?
>
> It still looks much safer to simply install the links only after names become unique
> and probably don't do that during WPA compilation at all, since we never output
> any assembly.
Original links are not wrong. Links just may be shared by many decl
pairs. If we always privatize whole pair and never privatize only one
its member, then we don't break existing links but create new ones for
newly created assembler names.
Agree it may be simplified by producing links later and it is useless
for WPA because links are not streamed out. Probably set links in
lto_main before symbol_table::compile call?
Thanks,
Ilya
>>
>> I don't see how 1-1 matching may be achieved now for instrumented
>> functions. We have two cgraph_nodes which actually represent the same
>> function. Thus single real symbol for two nodes.
>
> Yeah, this is quite important change in the design assumptions for symtab that
> is why we need so many places to fix...
>
> Honza
>>
>> Thanks,
>> Ilya
>>
>> >
>> > Honza