This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC's ICF vs. gold's ICF
- From: Martin Liška <mliska at suse dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>, Frank Tetzel <s1445051 at mail dot zih dot tu-dresden dot de>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 22 Jan 2019 09:46:19 +0100
- Subject: Re: GCC's ICF vs. gold's ICF
- References: <20190115141110.5bc23421@archvm> <CAFiYyc3XtR3V8yhRYaM6bUdvGTOe14ajwNpY-qciMPh18Oy4AQ@mail.gmail.com> <20190115163538.3edc36bf@archvm> <CAFiYyc14jcB_qFJ2uZsf1_nNXSFDUm7Cmc3tbXfNYk=-rgTxdw@mail.gmail.com>
On 1/15/19 4:49 PM, Richard Biener wrote:
> On Tue, Jan 15, 2019 at 4:43 PM Frank Tetzel
> <s1445051@mail.zih.tu-dresden.de> wrote:
>>
>>>> why is the ICF pass in gcc not folding member functions which
>>>> depend on a template parameter but happen to generate identical
>>>> code? Is it because it is not identical on the IR level in the
>>>> compiler? Can I somehow dump the IR in text form?
>>>
>>> You can look at the ICF dump generated when you pass
>>> -fdump-ipa-icf-details
>>>
>>> And yes, ICF has to consider IL differences that may result in
>>> different allowed followup optimizations while when the IL is final
>>> (such as link-time) no such considerations have to be made. A very
>>> simple example would be signed vs. unsigned integer multiplication
>>> where from the former IL overflow would be undefined and
>>> optimizations can exploit that while not for the latter.
>>
>> Thanks for the information. If I read the dump correctly, it also
>> considers the return type and that seems to be the problem in my tiny
>> test program.
>>
>> snippet from dump:
>>
>> group: with 1 classes:
>> class with id: 1, hash: 2170673536, items: 2
>> MyArray<float, 1024>::operator[](unsigned int)/4 MyArray<int, 1024>::operator[](unsigned int)/3
>> false returned: 'alias sets are different' (compatible_types_p:244)
>> false returned: 'result types are different' (equals_wpa:676)
>>
>> The body of the functions look identical, but the return type differs.
>> So in C++, ICF is "disabled" for templated functions with a template
>> parameter as return type.
>>
>> But why is the return type preventing code folding? Because we do not
>> know the calling convention at this point in time?
>
> Kind-of. Probably because ICF is not prepared to "fixup" callers
> and insert no-op type conversions to make the IL valid. Martin should
> know.
I must confirm that current implementation of IPA ICF is over-sensitive to
types. I'm planning to work on that in next stage1 in order to make
it more fine grain. Moreover, current implementation can't merge alias
sets of types where merge would be huge benefit. That needs to be discussed
with Richard I guess.
Martin
>
> The analysis could certainly be enhanced to avoid comparing some bits
> that will not be relevant in the end.
>
> Richard.
>